Cabal question: Generated data files

Hi,

First off, this list seems a bit off-topic for a question about Cabal,
but its what the web page told me to do: http://haskell.org/cabal/ -
if this isn't the place for this email, could someone update the web
page?

The question is about generated data files, specifically for Hoogle.

Hoogle generates search databases, which I want to be installed as
read-only data, in datadir. For a release I want to bundle up these
databases in the tarball, pregenerated. I don't want to include these
databases in the darcs version (they are fairly specific to a
particular version and regularly changing), but I do want people to be
able to build the darcs version using cabal. To generate these
databases requires a second Haskell program (included in the darcs
repo), and an installed copy of the same version of Hoogle.

So, I want to generate database files, which can only be done after
install time, but which I then want to be installed. Is there any way
to acheive this? Or some better idea? Currently I just generate the
databases and have the .cabal file reference them, which means the
darcs version can't be compiled with Cabal.

Thanks

Neil

Proposal: Reserved module namespace for packages on Hackage

In the interests of reducing module name collisions, I suggest
reserving part of the module name space for individual packages on
Hackage. Specifically, I'm suggesting that a new top-level module
name, "Lib", be added to the module naming conventions, and that the
children of "Lib" be reserved for the Hackage package with the same
name. That is, "Lib.Foo" and "Lib.Foo.*" would be reserved for the
package "Foo" on Hackage.

This would not require packages to *use* this namespace. However,
packages that do use it would have a greatly reduced chance of
conflicting with other packages.

Implementation costs are minor. At most, we might want some code in
Hackage to prevent packages from using module names reserved for other
packages. At the least, all we need to do is add "Lib" to the list of
allowable top-level module names. Developers who object to giving the
provenance of a module in its name are free to take their chances with
the rest of the module hierarchy.

Mapping package names to module names is mostly straightforward.
According to the Cabal documentation, a package name consists of one
or more alphanumeric words separated by hyphens, where each word
contains at least one letter. Since hyphens aren't allowed in module
names, they would get mapped to underscores, which are not allowed in
package names. Thus, "Lib.Foo_Bar" would be reserved for package
"Foo-Bar".

It's less obvious what to do with packages whose names start with
lower-case letters or digits. I see three possible solutions:

Re: laziness of intersperse

On Sun, Aug 17, 2008 at 9:43 AM, Barton C Massey <bart <at> cs.pdx.edu> wrote:
>  Maybe something like
>
>    intersperse _ [] = []
>    intersperse sep (x : xs) =
>        x : concatMap ((sep :) . (: [])) xs
>
> is clearer (maybe), but I doubt it's as efficient (although
> I haven't checked).

concatMap is a bit tricky when it comes to performance.  I also think
the low-level loop implementation that duncan showed is rather
readable.

> Thanks much for the corrections!  (I hope it's OK to do this on-list.)

Of course.  Nobody gets it right the first time.  (Well, maybe Oleg.
But then again we have some doubts whether he is from this planet or,
if he is, perhaps from the future.)

laziness of intersperse

(This is the same issue as http://www.haskell.org/pipermail/haskell/ 
2004-March/013739.html but there was no follow-up at that time.)

The intersperse library function is not as lazy as it could be.  The  
current definition of intersperse is

intersperse             :: a -> [a] -> [a]
intersperse _   []      = []
intersperse _   [x]     = [x]
intersperse sep (x:xs)  = x : sep : intersperse sep xs

For any list (x:xs) not containing _|_, intersperse sep (x:xs) is a  
list of the form (x:...); yet intersperse sep (x:_|_) = _|_ because  
the pattern match on the second equation diverges.  A better  
definition would be

intersperse _ [] = []
intersperse sep (x:xs) = x : intersperseWithPrefix xs
   where intersperseWithPrefix [] = []
         intersperseWithPrefix (x:xs) = sep : x :  
intersperseWithPrefix xs

(slightly modified from http://www.haskell.org/pipermail/haskell/2004- 
March/013741.html)

An application: There was a question on #haskell about how to compute  
the "ruler" sequence [1,2,1,3,1,2,1,4,1,2,1,3,1,2,1,5,...].  The  
definition

ruler = fix ((1:) . intersperse 1 . map (1+))

darcs patch: Fix oversight in Control.OldException

Sat Aug 16 15:26:31 CEST 2008  Bertram Felgenhauer <int-e <at> gmx.de>
  * Fix oversight in Control.OldException
  The NonTermination constructor slipped through in the Exception instance.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

proposal #2517: remove 'pure' method from Arrow class

The Arrow class as originally defined by John Hughes had methods arr, >>>
and first.  (>>> has since been moved by #1773 to the Category class.)
When writing the "Fun of Programming" paper, I added pure as a synonym
for arr, because Richard Bird preferred it.  However this name hasn't
caught on, and now it clashes with a method in the Applicative class,
so I propose to remove it.

The usual practice would be to deprecate the name in one release and
remove it in the following one, but I propose to remove it in one step
because
 * no-one seems to be using this name, and
 * backward compatibility has been broken anyway by the Category split
   (#1773).
The only people who will be bitten by the change are those who import
Control.Arrow hiding pure, and they wouldn't be warned by deprecation.

ANN: Initial release of Language.C (language-c-0.3)

Hi all,

I'm pleased to announce the first release of Language.C, a library for  
analysing and generating C code.

This release features

    * A reasonably well tested parser handling and recording all of  
C99 and most GNU extensions, most notably gcc's attribute syntax.

    * A pretty printer generating source code from the AST, covering  
the same language subset as the parser.

    * A preview of the analysis framework, including functionality for  
dissecting C's cruel type and variable declarations.

Places:

   * The project's homepage is located at http://www.sivity.net/projects/language.c 
  (Getting Started, Bug Tracker)

   * The package is available via hackage (language-c-0.3)

   * darcs repo: http://code.haskell.org/language-c

   * API docs: http://code.haskell.org/~bhuber/docs/language-c-latest/

The library originated from the C-related code in c2hs
(http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ 
), and is the topic of my SoC project, mentored by Iavor Diatchki.  

cabal-install

"cabal install foo" seems a nice (in fact, indispensible) idea,
but I don't see how to do the following with *one* command,
for package "foo" and all its dependencies:
* download and build as user, but install as root
* also build and install haddockumentation for each of the packages
Best regards, J.W.

Unhelpful library documentation

I don't know if everyone has seen this, so I thought I'd mention this: <http://lukeplant.me.uk/blog.php?id=1107301692>

> "Haskell API docs suck. A lot."

"Haskell API documentation is very lacking for newbies. For instance, I want to understand how to create
and use regexes. If you start at Text.Regex.Posix documentation, it tells you that =~ and =~~ are the high
level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions
are not actually documented at all!"

"Since Haskell libraries are almost always implemented by Haskell gurus, and they implement them with
themselves in mind (I have no objection to this, they are enthusiasts working for free), they use lots of
clever code and advanced Haskell techniques. But this means that if you want people to actually use these
libraries (and by consequence Haskell itself), the documentation for Haskell libraries has to be about
an order of magnitude better than anything you'd find anywhere else. I suspect it is at least an order of
magnitude worse than for something like .NET APIs, which means that relatively speaking the
documentation of Haskell is currently in an absolutely dire state."

These are all interesting points, but I found most interesting the conclusion:

"Moving forward, I guess one problem is contributing to a library's documentation. There is nothing on the
API doc pages that shows you how to do this. I suspect you need to check out the source with darcs (not
something I do normally, I just use cabal) and then start email patches or something. Even then, I don't
know if I would contribute any documentation -- 'howto' style documentation seems out of place on the API
pages, but it is desperately needed."

So, what can be done here? Offhand, I want to suggest adding a link to some sort of tutorial module or wiki
page. Each page *does* mention that 'Maintainer libraries <at> haskell.org', but this really isn't
helpful; it doesn't tell you where to get the original library source code, how to edit, what libraries@
*is* (anyone with a brain in their head is going to know that libraries@ is some sort of group interface, and
is going to refrain from emailing it until they know that they aren't cluelessly spamming/offending

PROPOSAL: More base package breakup

Hi all,

This is trac #1338:
    http://hackage.haskell.org/trac/ghc/ticket/1338#comment:14
    http://hackage.haskell.org/trac/ghc/attachment/ticket/1338/packagegraph.png

Initial deadline: 21 Aug (2 weeks).

The base package is still a large, unwieldy beast, making it hard to
develop and debug. If possible, I'd like to cut it down a bit more
before the 6.10 release.

I won't inline all the details here, as it's a huge amount of text and
an image, but basically I'm proposing to:

* Create packages:
    timeout, unique, concurrent,
    st,
    system, numeric, generics,
    version, getopt, debug, printf
    ghc-exts
* Merge what I've listed as "control" into "containers"

There's definitely a "foreign" package fighting to get out too, but that
needs more work before we can set it free.

An important point to note is that Simon Marlow has made a base 3
compatibility library that will come with GHC 6.10, and will provide the
same interface as the base library that came with 6.8, so breaking

Library submission process for tweaks / bugfixes

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries