On Thu, 2013-03-21 at 17:51 -0400, Isaac Dupree wrote:
On 03/18/2013 12:55 PM, Duncan Coutts wrote:
[...] it
is not simply the outline parser for cabal-style files that we're
talking about. We also need parsers/pretty printers for all the various
little types that make up the info about
On 03/18/2013 12:55 PM, Duncan Coutts wrote:
[...] it
is not simply the outline parser for cabal-style files that we're
talking about. We also need parsers/pretty printers for all the various
little types that make up the info about packages, like versions,
package names, package ids, version
On 18 March 2013 03:08, Simon Peyton-Jones simo...@microsoft.com wrote:
Is it essential, or even sensical, that the serialization format GHC needs
for storing package info bear any relation to the human authored form? If
not, the split out of the package types could be accomplished in a way
Is it essential, or even sensical, that the serialization format GHC needs for
storing package info bear any relation to the human authored form? If not, the
split out of the package types could be accomplished in a way where GHC uses
simple show/read(P) style serialization for storage of
On Sun, 2013-03-17 at 21:04 +0100, Henning Thielemann wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human
readable format. The only place I can think of it being used is in the
package database, but we could use either
On Sun, 2013-03-17 at 19:27 +, Ian Lynagh wrote:
On Sun, Mar 17, 2013 at 09:57:25AM -0700, Mark Lentczner wrote:
Is it essential, or even sensical, that the serialization format GHC needs
for storing package info bear any relation to the human authored form? If
not, the split out of
On Mon, Mar 18, 2013 at 12:34:16PM +, Duncan Coutts wrote:
Then you can have ghc-pkg depend on Cabal and use that for the
human-readable bits, but since that's a program then it doesn't expose
the Cabal lib dependency. Then ghc (and hence the ghc lib) would not
depend on Cabal, but it
On Mon, 2013-03-18 at 12:43 +, Ian Lynagh wrote:
On Mon, Mar 18, 2013 at 12:34:16PM +, Duncan Coutts wrote:
Then you can have ghc-pkg depend on Cabal and use that for the
human-readable bits, but since that's a program then it doesn't expose
the Cabal lib dependency. Then ghc
On Sun, Mar 17, 2013 at 09:57:25AM -0700, Mark Lentczner wrote:
Is it essential, or even sensical, that the serialization format GHC needs
for storing package info bear any relation to the human authored form? If
not, the split out of the package types could be accomplished in a way
where
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human
readable format. The only place I can think of it being used is in the
package database, but we could use either Read/Show for that, or just
exclusively use the binary format.
I
On Sun, Mar 17, 2013 at 09:04:58PM +0100, Henning Thielemann wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human
readable format. The only place I can think of it being used is in the
package database, but we could use either
On Sun, 17 Mar 2013, Ian Lynagh wrote:
On Sun, Mar 17, 2013 at 09:04:58PM +0100, Henning Thielemann wrote:
On Sun, 17 Mar 2013, Ian Lynagh wrote:
I think it would be feasible to stop GHC itself from using the human
readable format. The only place I can think of it being used is in the
On 03/15/2013 04:33 PM, Duncan Coutts wrote:
On Fri, 2013-03-15 at 05:19 +0100, Bardur Arantsson wrote:
On 03/14/2013 11:01 PM, Duncan Coutts wrote:
On Thu, 2013-03-14 at 11:15 -0700, Jason Dagit wrote:
On Thu, Mar 14, 2013 at 11:01 AM, Bardur Arantsson
s...@scientician.netwrote:
On
I'd love to have a proper parser and source-location-aware AST for sake of
editor/IDE tools, so +1 from me. If you don't end up doing this after all,
I'd still like to see your parser in a separate package, although I
understand if you don't feel like maintaining two parsers especially given
the
Duncan Coutts wrote:
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend on parsec
and thus it would become a core package, rather than just a HP package.
So this would affect both GHC and the HP,
* Heinrich Apfelmus apfel...@quantentunnel.de [2013-03-15 10:38:37+0100]
Duncan Coutts wrote:
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend on parsec
and thus it would become a core package,
* Ivan Lazar Miljenovic ivan.miljeno...@gmail.com [2013-03-15 22:12:47+1100]
On 15 March 2013 22:05, Roman Cheplyaka r...@ro-che.info wrote:
* Heinrich Apfelmus apfel...@quantentunnel.de [2013-03-15 10:38:37+0100]
Duncan Coutts wrote:
Hi folks,
I want to give you advance notice that I
On 14 Mar 2013, at 14:53, Duncan Coutts wrote:
Why did I choose parsec? Practicality dictates that I can only use
things in the core libraries, and the nearest thing we have to that is
the parser lib that is in the HP.
I fully agree that a real parser is needed for Cabal files. I
On Fri, 2013-03-15 at 10:10 +0100, Herbert Valerio Riedel wrote:
Duncan Coutts duncan.cou...@googlemail.com writes:
[...]
I've been doing regression testing against hackage and I'm satisfied
that the new parser matches close enough. I've uncovered all kinds of
horrors with .cabal
On Fri, 2013-03-15 at 12:37 +0800, Conrad Parker wrote:
On 14 March 2013 22:53, Duncan Coutts duncan.cou...@googlemail.com wrote:
I've been doing regression testing against hackage and I'm satisfied
that the new parser matches close enough. I've uncovered all kinds of
horrors with .cabal
On Fri, 2013-03-15 at 05:19 +0100, Bardur Arantsson wrote:
On 03/14/2013 11:01 PM, Duncan Coutts wrote:
On Thu, 2013-03-14 at 11:15 -0700, Jason Dagit wrote:
On Thu, Mar 14, 2013 at 11:01 AM, Bardur Arantsson
s...@scientician.netwrote:
On 03/14/2013 03:53 PM, Duncan Coutts wrote:
Hi
On Thu, 2013-03-14 at 14:53 +, Duncan Coutts wrote:
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend on parsec
and thus it would become a core package, rather than just a HP package.
So this
On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts duncan.cou...@googlemail.com
wrote:
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend on parsec
and thus it would become a core package, rather than
On Thu, 2013-03-14 at 16:06 +0100, Gregory Collins wrote:
On Thu, Mar 14, 2013 at 3:53 PM, Duncan Coutts duncan.cou...@googlemail.com
wrote:
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend
This GHC dependency on Cabal is putting a rather troubling constraint
in Cabal's evolution, which in my opinion is a serious problem. When I
first took a look at the dependencies between GHC and Cabal I found it
a bit strange that GHC would depend on Cabal as I would expect GHC to
be as low in the
On Thu, 2013-03-14 at 12:22 -0300, Administrator wrote:
This GHC dependency on Cabal is putting a rather troubling constraint
in Cabal's evolution, which in my opinion is a serious problem. When I
first took a look at the dependencies between GHC and Cabal I found it
a bit strange that GHC
On Thu, Mar 14, 2013 at 7:53 AM, Duncan Coutts duncan.cou...@googlemail.com
wrote:
Hi folks,
I want to give you advance notice that I would like to make Cabal depend
on parsec. The implication is that GHC would therefore depend on parsec
and thus it would become a core package, rather than
Yes I think that'd be a great plan. It's bizarre that GHC depends on *all* of
Cabal, but only uses a tiny part of it (more or less the Package data type I
think).
Simon
| -Original Message-
| From: cabal-devel-boun...@haskell.org
[mailto:cabal-devel-boun...@haskell.org]
| On
On Thu, 2013-03-14 at 09:39 -0700, Jason Dagit wrote:
Why did I choose parsec? Practicality dictates that I can only use
things in the core libraries, and the nearest thing we have to that is
the parser lib that is in the HP. I tried to use happy but I could not
construct a grammar/lexer
On Thu, 2013-03-14 at 16:44 +, Simon Peyton-Jones wrote:
Yes I think that'd be a great plan. It's bizarre that GHC depends on
*all* of Cabal, but only uses a tiny part of it (more or less the
Package data type I think).
The sensible way to split it (I think) would be like this:
On 03/14/2013 03:53 PM, Duncan Coutts wrote:
Hi folks,
Why did I choose parsec? Practicality dictates that I can only use
things in the core libraries, and the nearest thing we have to that is
the parser lib that is in the HP. I tried to use happy but I could not
construct a grammar/lexer
On Thu, Mar 14, 2013 at 11:01 AM, Bardur Arantsson s...@scientician.netwrote:
On 03/14/2013 03:53 PM, Duncan Coutts wrote:
Hi folks,
Why did I choose parsec? Practicality dictates that I can only use
things in the core libraries, and the nearest thing we have to that is
the parser lib
* Duncan Coutts duncan.cou...@googlemail.com [2013-03-14 17:12:14+]
The InstalledPackageInfo and its parser is what ghc and ghc-pkg
primarily use (though there's the opportunity to share code for handling
package indexes) and that type and that parser are also going to end up
using text
On Thu, 2013-03-14 at 21:29 +0200, Roman Cheplyaka wrote:
* Duncan Coutts duncan.cou...@googlemail.com [2013-03-14 17:12:14+]
The InstalledPackageInfo and its parser is what ghc and ghc-pkg
primarily use (though there's the opportunity to share code for handling
package indexes) and
On Thu, 2013-03-14 at 11:15 -0700, Jason Dagit wrote:
On Thu, Mar 14, 2013 at 11:01 AM, Bardur Arantsson
s...@scientician.netwrote:
On 03/14/2013 03:53 PM, Duncan Coutts wrote:
Hi folks,
Why did I choose parsec? Practicality dictates that I can only use
things in the core
On 03/14/2013 11:01 PM, Duncan Coutts wrote:
On Thu, 2013-03-14 at 11:15 -0700, Jason Dagit wrote:
On Thu, Mar 14, 2013 at 11:01 AM, Bardur Arantsson
s...@scientician.netwrote:
On 03/14/2013 03:53 PM, Duncan Coutts wrote:
Hi folks,
Why did I choose parsec? Practicality dictates that I can
On 14 March 2013 22:53, Duncan Coutts duncan.cou...@googlemail.com wrote:
I've been doing regression testing against hackage and I'm satisfied
that the new parser matches close enough. I've uncovered all kinds of
horrors with .cabal files in the wild relying on quirks of the old
parser. I've
37 matches
Mail list logo
