BNFC should reject 'bad' filenames names instead of silently sanitizing them

[oskarabrahamsson]

BNFC generates various names (files, directories, classes, ...) based on the filename of the input grammar (e.g. Lang.cf). Not all backends will be able to deal with all legal choices of Lang.cf, however. In those cases, BNFC chooses other names (see e.g. #325 and 22b5483).

I think that BNFC should reject all choices of Lang.cfthat are somehow incompatible with the backend. This behavior would be less surprising, and more in line with how BNFC deals with unsupported names in other situations: for instance, Foo. Foo ::= Bar ; is not legal when using the Java backend, so BNFC rejects it.

[andreasabel]

I agree, BNFC's filename sanitization is a bit odd. For instance, Foo1.cf is shortened to stem Foo in some backends (Haskell/Ocaml/Java), dropping the number.
This can however be utilized by developing versions of a grammar called Foo1.cf, Foo2.cf, etc. ending up in the same files.
The main question is how backwards compatible we should be.
In this present case, breaking backwards compatibility is probably harmless, if reported like

ERROR: Foo1 isn't a legal name for a grammar in the Haskell backend (since BNFC version x.y.z).
Legal names are...

However, in case someone really wants one grammar compiled in several backends, there could be mutually exclusive conditions on what legal file identifiers are (e.g. Haskell modules start with a capitial letter, Java packages need to be all lowercase).
Concretely, it could hit our parameterized testsuite hard.

A new regime on filenames could be implemented under a flag like --strict-filename (and its opposite, the current behavior, under --sanitize-filename).

Out of curiosity, what is case 0 for this bug report?

[oskarabrahamsson]

I came across this when I found that some of our code apparently relied on a one-to-one correspondence between Lang.cf and the names of directories generated by BNFC: clearly not best practice.

I think it makes sense to fail early as the default (i.e., the --strict-filename case being applied by default), while supporting the old behavior via options. However, if this is not possible, --strict-filename is still a useful addition.

Another useful addition could be a flag --name NAME which would tell BNFC to generate names as if NAME.cf was the filename of the supplied grammar. In this mode, BNFC should always fail unless NAME is compatible with the chosen backend.

[andreasabel]

I now see that our PLT students shoot themselves in the foot unknowingly by naming their grammar lab1.cf.
So I am tending to enforce a discipline on grammar file names (that could be overwritten by a flag).

[andreasabel]

What are legal module/package names?

• Haskell module: Uppercase Haskell identifiers (letter, digits, underscores, prime): https://www.haskell.org/onlinereport/lexemes.html
• Ocaml module: same as Haskell: https://ocaml.org/manual/names.html#module-name
• Java package: Java identifiers, separated by dot. Should start with lowercase letter, best practice: all lowercase.

Where does sanitization happen?

• Haskell: CamlCase

  bnfc/source/src/BNFC/Backend/Haskell/HsOpts.hs

  Lines 70 to 71 in 07b9772

  	withLang :: Options -> String -> String
  	withLang opts name = name ++ mkName [] CamelCase (lang opts)

  bnfc/source/src/BNFC/Backend/Haskell/HsOpts.hs

  Lines 78 to 87 in 07b9772

  	-- >>> mkMod withLang "Abstract" defaultOptions { lang = "abc" }
  	-- "AbstractAbc"
  	-- >>> mkMod noLang "Abstract" defaultOptions { lang = "abc" }
  	-- "Abstract"
  	-- >>> mkMod withLang "Abstract" defaultOptions { lang = "abc", inPackage = Just "A.B.C" }
  	-- "A.B.C.AbstractAbc"
  	-- >>> mkMod withLang "Abstract" defaultOptions { lang = "abc", inDir = True }
  	-- "Abc.Abstract"
  	-- >>> mkMod withLang "Abstract" defaultOptions { lang = "abc", inDir = True, inPackage = Just "A.B.C" }
  	-- "A.B.C.Abc.Abstract"

  bnfc/source/src/BNFC/Backend/Haskell/HsOpts.hs

  Lines 120 to 128 in 07b9772

  	-- >>> mkNamespace defaultOptions { lang = "bla_bla", inDir = True }
  	-- "BlaBla"
  	-- >>> mkNamespace defaultOptions { lang = "bla", inDir = True, inPackage = Just "P"}
  	-- "P.Bla"
  	mkNamespace :: Options -> FilePath
  	mkNamespace opts = intercalate "." $ catMaybes [inPackage opts, dir]
  	where
  	dir | inDir opts = Just (mkName [] CamelCase (lang opts))
  	| otherwise = Nothing

• OCaml: CamlCase

  bnfc/source/src/BNFC/Backend/OCaml.hs

  Lines 52 to 54 in 07b9772

  	-- | Turn language name into a valid ocaml module identifier.
  	sanitizedLang :: SharedOptions -> String
  	sanitizedLang = camelCase_ . lang

• Java: snake_case

  bnfc/source/src/BNFC/Backend/Java.hs

  Lines 59 to 62 in 07b9772

  	makeJava :: SharedOptions -> CF -> MkFiles ()
  	makeJava opt = makeJava' opt{ lang = mkName javaReserved SnakeCase $ lang opt }
  	-- issue #212: make a legal package name, see also
  	-- https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

• C: no sanitization needed, as there is no concept of module in C.
• C++: ditto, uses just files and include.