[Hackage] #478: allow comments on any line,
don't require '.' for blank lines
Hackage
trac at galois.com
Sat Dec 19 22:18:27 EST 2009
#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.)
We only know where the field starts, not where the error is detected.
> 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...
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.
Right, though I guess if -- needs to be passed then Cabal should do it
automatically.
> 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.
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
More information about the cabal-devel
mailing list