[Hackage] #478: allow comments on any line, don't require '.' for blank lines

[Hackage]

#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.

 I agree that it's ugly, but the current situation is also not clear.

 > 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
 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