[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