#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 creswick): Replying to [comment:3 duncan]:
Replying to [comment:2 creswick]:
The error output for this could at least mention that comments aren't allowed at the end of lines.
This is tricky because we do not know they are there.
ah.. that's too bad. I take it the parser would need to be substantially augmented to include the reason for the parse failure? (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.)
There is also an inconsistency in the syntax for build-depends and
some other lists (eg: extra-source-files). Comments at the end of a line in an extra-source-files list do not cause a parse error, yet they do when added to the end of a line in a build-depends list.
It's not actually inconsistent. Remember that "-- blah" in a field is
considered as part of the field. So for build-depends, that does not parse, but it's perfectly ok to have a source file called "--" and "blah". Of course it will fail when trying to sdist because the files do not exist. Right... I guess I was conflating something different that struck me as inconsistent: build-depends seems to be comma-delimited, while extra- 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...
In my opinion, the simplest solution is to require that -- be escaped. (eg: \-\-, or \-- ) when it is not used as a comment delimiter.
That's fairly ugly and will not reduce confusion because people will not know that they can or should use that syntax.
As I mention in the original description, I think the thing to do is to consider whether allowing "-- " as the start of a comment could possibly cause problems in fields like ghc-options, since "--" is a valid value to
I agree that it's ugly, but the current situation is also not clear. pass to a program. 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 problem. 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.) -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/478#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects