Package names starting with a numeric character cause assembler errors

[mboes]

Hi,

When trying to compile a package named 9pH, I get the following error:

/usr/bin/ghc -O -package-name 9pH-0.1 --make -XOverloadedStrings -XPatternGuards -XTemplateHaskell Network.GpH.Protocol.Derive      
[1 of 1] Compiling Network.GpH.Protocol.Derive ( Network/GpH/Protocol/Derive.hs, Network/GpH/Protocol/Derive.o )
/tmp/ghc4263_0/ghc4263_0.s: Assembler messages:

/tmp/ghc4263_0/ghc4263_0.s:18137:0:
     Error: junk at end of line, first unrecognized character is `9'

/tmp/ghc4263_0/ghc4263_0.s:18165:0:
     Error: junk at end of line, first unrecognized character is `9'

/tmp/ghc4263_0/ghc4263_0.s:18166:0:
     Error: unrecognized symbol type "9"

/tmp/ghc4263_0/ghc4263_0.s:18166:0:
     Error: junk at end of line, first unrecognized character is `p'

/tmp/ghc4263_0/ghc4263_0.s:18167:0:
     Error: junk at end of line, first unrecognized character is `9'

/tmp/ghc4263_0/ghc4263_0.s:18168:0:
     Error: junk at end of line, first unrecognized character is `p'

/tmp/ghc4263_0/ghc4263_0.s:18172:0:
     Error: junk at end of line, first unrecognized character is `p'

/tmp/ghc4263_0/ghc4263_0.s:18245:0:
     Error: junk at end of line, first unrecognized character is `p'
...

It turns out that if I remove '-package-name 9pH-0.1' from the command line, or change the package name, then the compilation completes without error.

It seems that either:

1. Package names starting with numeric characters should be banned. In which case it should be clearly documented in the user's guide and/or in the cabal manual and the compiler should check this early on in the compilation.
2. Package names starting with a numeric character should be allowed. In which case package names should be mangled appropriately to avoid having the assembler complain.

In my view option 2 would be preferable.

Many thanks,

Mathieu

[simonpj]

I agree with (2). If digits aren't acceptable as leading characters we'd better encode them.

I think the fix is simple:

• In Encoding.zEncodeString treat the first character specially, by z-encoding even digits (which are not otherwise encode). A good encoding would be 0 --> z0 etc.
• Similarly in decoding we'd need to treat the first character specially.

Alternatively we could *always* z-encode digits. But that seems overkill (eg base-3.5 would become basezmz3ziz5 rather than (as now) basezm3zi5). But it's no big deal either way.

Ian would you like to decide and execute?

Simon

[igloo]

Will do

[igloo]

Fixed in HEAD and 6.10:

Fri Feb 27 18:00:29 GMT 2009  Ian Lynagh <igloo@earth.li>
  * z-encode digits at the start of a symbol name; fixes trac #2997
  Digits already have a couple of meanings in z-encoding (Z3T is a tuple,
  and z123U is a unicode character), so we encode digits as unicode
  characters to avoid trying to squeeze in another meaning.
  
  Also removed a little GHC < 6.2 compatibility hack.