September 2016 - Haskell-community

haskell.org download page
by Jason Dagit 20 Nov '16

20 Nov '16

Hello all, I just realized that the Minimal installer listed first on the Downloads page (https://www.haskell.org/downloads) is deprecated and "dead". This creates an unfortunate situation where our top suggested way to get haskell immediately tells the user it's dead. I think that we should remove mention of the minimal installer ASAP on the grounds that the HP now comes in minimal and full variants. Furthermore, I would like to make the recommendation that we list the HP above other methods as even the minimal HP installer ships with stack (at least on windows it does). Between the two changes, I think the first one is crucial and the second one is merely reasonable. Thanks, Jason

22 39

technical thoughts on stack
by Richard Eisenberg 27 Sep '16

27 Sep '16

I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray. First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it. My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it. My approach: 1. `brew install haskell-stack`. Success. At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to 2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc > Right Nothing At the end, I am helpfully told > To use this GHC and packages outside of a project, consider using: > stack ghc, stack ghci, stack runghc, or stack exec > So I then 3. `stack ghci`. My computer’s first reaction is to say > Run from outside a project, using implicit global project config > Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml > Error parsing targets: The specified targets matched no packages. > Perhaps you need to run 'stack init'? > Warning: build failed, but optimistically launching GHCi anyway > which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected. Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I 4. `stack ghc --version`. This command reports > Invalid option `--version’ Grumble. It seems I can’t interact with GHC directly. ———— At this point, I am reminded why I dislike stack: **It’s optimized for a different workflow than I use.** And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows. From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines. In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment. I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow. The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences. But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings. A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant. B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`). There’s more good news here! Both of these problems are really easy to fix. To fix (A), someone just has to write the tutorial. To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH. I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly. Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :) So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)? I’m looking forward to hearing your thoughts. Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

21 50

Standard package file format
by Harendra Kumar 20 Sep '16

20 Sep '16

I am starting a new thread for the package file format related discussion. >From a developer's perspective, the major benefit of a standard and widely adopted format and is that people can utilize their knowledge acquired from elsewhere, they do not have to go through and learn differently looking and incomplete documentation of different tools. The benefit of a common config specification is that developers can choose tools freely without worrying about learning the same concepts presented in different ways. Multiple formats flying around also create a psychological impression of complexity in the ecosystem for newcomers. If we have consistency there are better chances of attracting more people to the language ecosystem. I gather the following from the discussion till now: * We have cabal, YAML and TOML as potential candidates for a common package format which can additionally incorporate the concept of snapshots/package collections and potentially more extensions useful across build tools. * cabal has the benefit of incumbency and backward compatibility, it has shortcomings which are being addressed but it is still a format which is very specific to Haskell ecosystem. It is not a standard and not going to become one. We have to always deal with it ourselves and everyone coming to Haskell will have to learn it. * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A significant chunk of developer community is already familiar with it. It is being used by stack and by hpack as an alternative to cabal format. The complaint against it is that the specification/implementation is overly complex. * TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML and is being used by a few important projects but is still evolving and is not completely stable. On a first glance it looks pretty simple and a lot of other tools use a similar config format. It is aiming to become a standard and aiming for a wider adoption. As a next step we can perhaps do an hpack like experiment using the TOML format. That way we will have some experience with that as well and get to know if there are any potential problems expressing the existing cabal files. More thoughts, opinions on the topic will help create a better understanding about it. -harendra

12 17

Re: [Haskell-community] Standard package file format
by Herbert Valerio Riedel 17 Sep '16

17 Sep '16

On 2016-09-17 at 06:47:52 +0200, Bardur Arantsson wrote: [...] > I was actually curious about this, and it's interesting to note that > even JSON which was supposed to have *ONE STANDARD* now apparently has > two, an ECMA one and and IETF RFC (seems to be more recent). Btw, that's partly because ECMA and IETF weren't able to agree who "owns" JSON, for more details see https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-JSON -- hvr

1 0

[Haskell-cafe] Standard package file format
by Paolo Giarrusso 16 Sep '16

16 Sep '16

(Resending from right address) We're talking about *three* options: 1. syntax for pure Haskell values, which I'll call HSON (Haskell jSON). That's just an alternative to YAML/TOML/... That would need extensions to allow omitting optional fields entirely. 2. a pure Haskell embedded domain-specific language (EDSL) that simply generates cabal description records (GenericPackageDescription values). That would allow abstraction over some patterns but not much more. But that alone is already an argument for EDSLs—the one Harendra already presented. 3. a Haskell embedded domain-specific language (EDSL) designed for an extensible build tool, like Clojure's (apparently), SBT for Scala or many others. That would potentially be a rabbit hole leading to a rather *different* tool—with a different package format to boot. That can't work as long as all libraries have to be built using the same tool. But stack and cabal are really about how to manage package databases/GHC/external environments, while extensible build tools are about (a more powerful form) of writing custom setup scripts. I suspect some extensions might be easier if more of the actual building was done by the setup script, but I'm not sure. On 16 September 2016 at 10:57, yogsototh <yann.esposito(a)gmail.com> wrote: > >> I guess the overriding question I have here is: what is the PROBLEM being >> solved? > > > Let me share my experience with Clojure and lein. They use a clojure > hash-map for their configuration. So yes arbitrary code could be executed > and I believe this is a _very good thing_. > > Why? Because it makes it very easy to add sub-configuration that can be used > by third party plugin. For example: > > - a plugin that help the use of environment variables (lein-environ) which > is really helpful for application development (not so much for library > development) > - a plugin that use S3 for our private dependencies (not supported by > default by lein) > > > For deployment: we were able to add request to our API server that provide > not only the written version but also the git commit hash. So we could be > certain of the version of the server. Too much time there were sys/admin > deployment errors. And that could only be achieved because we were able to > run arbitrary command in the project description file. > > I certainly forget many other advantages of having a package description > format which is simply a data structure in the hosted language. But this has > by far my preference. > > - cabal is ok, but very imperfect, I generally need to have a lot of > copy/paste, I need to change it very often while writing application with > many dependencies > - JSON/YAML/TOML are simply not powerful enough to match all semantics we > might need to configure a project. For example we might want to have Set > instead of List for some properties. Or I don't know maybe ternary tree > structures. > > The point is: we pay a price by adding a step between the semantic and the > syntax. > While if our configuration format was in Haskell we could express the > semantic more directly. > > _______________________________________________ > Haskell-community mailing list > Haskell-community(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

4 6

Coordinating Hackage mirroring procedures
by Michael Snoyman 16 Sep '16

16 Sep '16

Hi all, Duncan, Herbert and I have been having a conversation the past few days about Hackage mirrors, kicked off by [1]. I requested we move the discussion to a public list in case others have some thoughts on what we're discussing. I'll do my best to summarize where we're at and what we're thinking of doing. Duncan and Herbert: please jump in and correct any mistakes :) * Upstream Hackage is hosted on a private IP address which is pointed at by a CDN. Currently, the connection between the CDN and Hackage is over plaintext HTTP, though that might switch to HTTPS soon. * Content on Hackage is secured via hackage-security, so users of cabal-install 1.24 are downloading data securely from the CDN. * There are three different Hackage mirroring tools available: * The original hackage-mirror tool in the Hackage repo itself, used during the migration from Hackage 1 to Hackage 2. It is not hackage-security aware * The hackage-mirror package on Hackage, which uploads to AWS S3. This is what hackage.fpcomplete.com uses, and feeds into Stack. It is also not hackage-security aware. * Herbert's hackage-mirror-tool, which uploads to Dreamhost S3, and ostensibly supports AWS S3 as well (though not yet tested). It _is_ hackage-security aware. * We don't really want three different tools, and we _do_ want the mirror tools to be hackage-security aware, especially given the lack of SSL between the CDN and Hackage itself. * The CDN has the potential to serve out-of-sync files, in particular deliver a 00-index.tar.gz file that refers to a certain package/version, but will return a 404 for the package tarball. This can cause confusion for downstream tools. The Dreamhost and AWS mirrors do not suffer from this. * There are three additional Git repositories providing Hackage metadata in different formats: all-cabal-files, all-cabal-hashes, and all-cabal-metadata. These are used by Stack, Stackage, Nix, and stackage.org. They feed off of the AWS S3 mirror. I believe the course of action we have planned is: 1. Ensure that Herbert's hackage-mirror-tool works correctly with AWS S3. 2. Switch over the hackage.fpcomplete.com AWS S3 mirror to use Herbert's hackage-mirror-tool, increasing its security, and allowing it to be listed as an official Hackage mirror. * This mirror will still be operated by FP Complete, making it less likely that a technical screw-up by one party will take down multiple mirrors by distributing the administration of systems. 3. Continue pointing all-cabal-files, -hashes, and -metadata at the AWS S3 mirror, which provides high reliability and will now be more secure based on the hackage-mirror-tool usage. This will scratch a few different itches: * A new mirror will be available on Hackage for cabal-install users * The AWS S3 mirror will be more secure * I can simplify some of my mirroring logic by not having to do workarounds for out-of-sync CDNs I think this is all doable, and pretty much within reach. I just wanted to get this out in the public first in case others have input, perhaps based on other use cases of these mirrors or repos that I'm not aware of. Michael [1] https://github.com/haskell/hackage-server/issues/537

1 0

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack
by Christopher Allen 14 Sep '16

14 Sep '16

I see what is meant now, but it's not really applicable. If I am co-developing a package and its dependencies, I add them as packages (not deps) to my stack.yaml and still get the warnings. Example: >From the stack.yaml for the package that uses my previous example's library: packages: - '.' - ../simple-library Then stack build'ing the project (uses-sl) that depends on simple-library which as a module with a warning: $ stack build simple-library-0.1.0.0: build Progress: 1/2 -- While building package simple-library-0.1.0.0 using: /home/callen/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o ) /home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "hello"’ One of the first things I did when figuring out Stack was to look at how Yesod used it: https://github.com/yesodweb/yesod/blob/master/stack.yaml On Wed, Sep 14, 2016 at 2:56 PM, David McBride <toad3k(a)gmail.com> wrote: > The rule of thumb seems to be, if you do a stack build and it decides to > build multiple packages, it hides this log info. > > I understand why it does that, I should be able to build lens without > worrying about tons of spurious output, but at the same time it is common > for me to have an entire tree of packages I'm developing and it often > obscures errors that are happening in my own packages. At the very least, > if it is only building local packages, I'd very much like to see that > output. > > On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier > <code(a)funwithsoftware.org> wrote: >> >> On 9/14/16 12:21 PM, Christopher Allen wrote: >>> >>> What are you talking about? >>> >>> $ stack build >>> simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) >>> simple-library-0.1.0.0: build >>> Preprocessing library simple-library-0.1.0.0... >>> [1 of 1] Compiling Lib ( src/Lib.hs, >>> .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) >>> >>> /home/callen/work/simple-library/src/Lib.hs:7:3: warning: >>> [-Wunused-do-bind] >>> A do-notation statement discarded a result of type ‘[Char]’ >>> Suppress this warning by saying ‘_ <- return "woot"’ >>> Preprocessing executable 'simple-library-exe' for >>> simple-library-0.1.0.0... >> >> >> Weird. That's not how it works for me: >> >> whiteandnerdy:normalize ppelleti$ stack build >> normalization-insensitive-2.0: unregistering (local file changes: >> Data/Unicode/NormalizationInsensitive.hs >> Data/Unicode/NormalizationInsensitive/Internal.hs) >> normalization-insensitive-2.0: configure >> normalization-insensitive-2.0: build >> normalization-insensitive-2.0: copy/register >> photos-0.1.0.0: configure >> photos-0.1.0.0: build >> photos-0.1.0.0: copy/register >> Completed 2 action(s). >> whiteandnerdy:normalize ppelleti$ cat >> .stack-work/logs/normalization-insensitive-2.0.log >> Configuring normalization-insensitive-2.0... >> Preprocessing library normalization-insensitive-2.0... >> [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( >> Data/Unicode/NormalizationInsensitive/Internal.hs, >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Internal.o >> ) >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: >> The import of ‘Data.Bool’ is redundant >> except perhaps to import instances from ‘Data.Bool’ >> To import instances alone, use: import Data.Bool() >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: >> The import of ‘otherwise, &&, <=, +’ >> from module ‘Prelude’ is redundant >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: >> Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: >> Convert ByteString to Text and then normalize >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: >> Top-level binding with no type signature: mode :: NormalizationMode >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: >> In the use of ‘B.normalize’ >> (imported from Data.ByteString.UTF8.Normalize): >> Deprecated: "Convert ByteString to Text and then normalize" >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: >> In the use of ‘B.normalize’ >> (imported from Data.ByteString.UTF8.Normalize): >> Deprecated: "Convert ByteString to Text and then normalize" >> [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( >> Data/Unicode/NormalizationInsensitive/Unsafe.hs, >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Unsafe.o >> ) >> [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( >> Data/Unicode/NormalizationInsensitive.hs, >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o >> ) >> >> Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: >> ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ >> In-place registering normalization-insensitive-2.0... >> Installing library in >> >> /Users/ppelleti/programming/haskell/normalize/.stack-work/install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM >> Registering normalization-insensitive-2.0... >> whiteandnerdy:normalize ppelleti$ >> >> I hadn't even been aware of these warnings in the package I was >> developing, until Harendra Kumar pointed them out to me, after I had >> uploaded a candidate to Hackage. >> >> --Patrick >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -- Chris Allen Currently working on http://haskellbook.com

2 2

:Documents Requested
by Sylvester 09 Sep '16

09 Sep '16

Dear haskell-community, Please find attached documents as requested. Best Regards, Sylvester

1 0

Next Steps in Downloads Page Discussion
by Gershom B 09 Sep '16

09 Sep '16

Hi all. Let me try to sum up the state of the discussion and propose next steps -- please feel free to disagree with my summary if you are so inclined. I'm trying to capture the current state and help move discussion, so if people feel this doesn't capture it, its good to know sooner rather than later. == Key Points == * We distinguish between "download method / installer" and "getting started". We add a new page "Getting Started" with links at the top level just like "Downloads / Community / Documentation / News". * The Downloads page points to the minimal platform installer (however named) that includes GHC, stack, cabal-install, and a few other binaries (but no extra global libraries). Below that we can have links to other mechanisms as well, but the minimal platform is the clearly distinguished recommended way. * The "Getting Started" page proceeds to describe next steps for new users to get up and running right away after installing the minimal platform. Since many people have made the case that for someone who hits the page without some prior guide, a stack workflow is the easiest to get running on and best documented at this time, I imagine this workflow will be stack-oriented. == Additional Considerations == * People have pointed to some issues in the windows platform installer. We are going to work to resolve these. A patch for one (which improves stack behavior when it can find ghc but not msys) is already submitted. Sorting out the other (which pertains to enterprise installs, not single-user installs) is underway. * As in the past, we shouldn't focus our discussions on what the answer is "for all time" -- tech will change, things will evolve. We should think of this as something that does the job reasonably well for say the next six months, give or take. == Next Steps == * There is a mock-up of a new download page already on github (Thanks so much Jacco!): https://github.com/haskell-infra/hl/issues/176 Under its "getting started" I would propose something like: 1. Download and run the Haskell Toolchain installer 2. Follow the _getting_started_guide_ to start running some code! with the latter linking to the new getting started page. I hope this is acceptable to people? Maybe some other bullet points should be there too... * I would like to solicit a kind volunteer or two to draft up what they think a "getting started guide" should look like so we can spawn a separate discussion on that. Given that we've decoupled this guide from the download page, it can afford, I think, to have a bit more text than just how to compile and run "hello world"... == a few other thoughts == We've had a productive discussion on this list, I think. But as many probably know, not all the discussions over this have been so positive. I just want to make a general point that has been nagging at me, and apologies for the sappiness that follows. While there is some commercial support, Haskell is an open-source language and community at heart that historically has and currently still relies on people volunteering their time. Be it in writing code, writing documentation, teaching others, and especially in working on tooling and infrastructure. (This goes all the way up to GHC which also runs on donated time and effort in many ways). Being run on volunteer steam is great in many ways. But it has one important caveat. People have to want to volunteer, because they enjoy the technical challenges, but especially because they want to help others, and because they find it rewarding to contribute to things which bring joy and benefit to others. All of us, working on installers, working on fundraising efforts, working on documentation, working on compilers and libraries, or trying to sort out weird issues with mailservers and proxying content delivery networks or php bugs impacting wikis or google-analytics tokens or whatever else, we're all here not because we have to be, but because we want to be. And that's great! But it is also precarious and fragile, because if it becomes not fun, or not rewarding, or we feel that what we do is being disparaged and attacked (and this goes for everyone, i think, on all sides of recent discussions) or diminished, then we change our calculus, and we stop wanting to participate, and stop wanting to fix things for others. And that's understandable. So, if we let our discussions or language play out in a way that can hurt others, can make them feel that their work is no good, or not appreciated, then they have no reason to want to help anymore. And they won't. And I can't blame them. And if we all start to hurt one another too much, it will become no fun for any of us, and then the whole endeavor falls apart. So I want to extend my gratitude and thanks to everyone working on any element of our open-source tooling and infrastructure, or even lending a voice to give insight into how to improve it. And I also want to ask us all to remember this in our interactions with one another, and to remember that people will say things we find unbelievably wrong at times, and discussions may stall at times, and things may get stuck for longer than we'd like. And we have every right to get frustrated when that happens. But we can't let our frustrations at difficult _situations_ turn into words that diminish other _people_, other potential collaborators, others also freely giving of their time trying to improve and help others, whatever our disagreements. I have more to say, but I'm not sure how, and this is long and inarticulate enough. Anyway, onto the next steps (I hope), and please everyone consider stepping forward to help with this stuff, in drafting language, or helping with design and implementation of the actual changes to the site (on which more volunteers welcome -- please email me!), etc. (By the way I want to put out more calls for help on more concrete infra stuff soon, not at all web related -- but in the immediate future, if you have experience running a mail server and dealing with the many painful hassles therein, and are willing to help a bit, please contact me soon). Best, Gershom

3 3

Bounce rate
by Tony Day 01 Sep '16

01 Sep '16

What might be useful is knowing what the visitor stats are, and the new visitor bounce rate.

2 1