#478: allow comments on any line, don't require '.' for blank lines ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:4 creswick]:
ah.. that's too bad. I take it the parser would need to be substantially augmented to include the reason for the parse failure?
Right. The parser we use for field contents gives us precisely no error information. Sadly we cannot have Cabal depend on packages like parsec so we're stuck with a useless parser for the moment.
(If we could get the offset into the cabal file that caused the parse error, then some post-processing might help infer the error output.)
Right... I guess I was conflating something different that struck me as inconsistent: build-depends seems to be comma-delimited, while extra-
We only know where the field starts, not where the error is detected. source-files (and others) look to be white-space delimited. I haven't dug into the source to look at the grammar yet though, so I may well be wrong here too. Anyway, that's out of scope for this ticket... That's quite true. That is inconsistent and I don't see an immediate reason for it. We should be able to allow space or commas in both.
gcc accepts some options that start with "--" so there *is* a conflict in at least some situations. The first to come to mind is cpp-options, and as you mentioned, files could contain "--" or even "-- " as well.
Since "--" is pretty commonly used to pass arguments to an underlying system, I think it's safe to assume that this will eventually become a
Right, though I guess if -- needs to be passed then Cabal should do it automatically. problem. Maybe, maybe not. Cabal doesn't provide a great deal of control over where flags go and -- makes all subsequent flags be interpreted as args.
What about supporting additional comment syntaxes, such as haskell's block comments, or the traditional '#'? (I'm not enamored by this idea either, by the way, but thought I'd toss it out there.)
I agree, there's not an obvious nice solution. As I see it, the problem is the confusion, not the inability to put comments on the same lines as fields. Once you realise it's not possible, it's not really a major restriction. So I don't see the need to add extra syntax to allow comments on the same line. That doesn't address the problem of people accidentally using -- comments. Perhaps if we decide that the ability to specify -- in the options fields is needed then we can tell people to use "--" instead. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/478#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects