Simplify runghc command line options

Currently there are three ways runghc can pass options to GHC:

1. unrecognized options are automatically passed to GHC
2. options after a -- are passed to GHC
3. --ghc-args=<arg> passes arg to GHC

The command line is difficult to comprehend and non-intuitive with all these different ways to pass options to GHC. Other than having multiple ways to do the same thing there are other problems too. For example:

1. The meaning of -- is overloaded, the usual meaning is that everything after it is non option or opaque args. This is difficult to explain and creates confusion.
2. To pass a filename starting with a dash we need something like runghc -- -- -prog.hs. Which is not a usual use case but it needs to be explained in the manual anyway.
3. It first appears that options after -- will be passed to GHC including those not starting with a - but that is not the case. For args not starting with a - we need to use --ghc-arg= so there is not much use of the -- anyway other than increased confusion.

I propose to do away with all other mechanisms other than the explicit --ghc-arg=<arg> method. This will make the documentation and understanding of the command straightforward and intuitive. Though the change will not be backward compatible. If backward compatibility is really needed we will have to use deprecation warnings for the unsupported methods and remove them from the official documentation and wait for some time before we actually remove them.

Trac metadata

Trac field	Value
Version	8.0.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	None
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

A problem with transparently passing unrecognized flags to ghc is a very confusing and hard to understand behavior like this:

runghc -package text-1.2.2.1 hello.hs

text-1.2.2.0:1:74:
    Not in scope: ‘main’
    Perhaps you meant ‘min’ (imported from Prelude)

What happened here is that runghc passed -package option to ghc but it did not pass text-1.2.2.0 which is being treated as the program name. This happens because of different ways to pass -package and its argument. So we will have to use --ghc-arg= for the arg like this:

runghc -package --ghc-arg=text-1.2.2.1 hello.hs
hello

If we had the same way to pass both the flag and the argument we won't have this very confusing behavior.

How about this:

runghc [runghc flags] module|filename [GHC flags] [-- [program args]]

Clarification:

• runghc -package .. would be an error, because -package is not a runghc flag, nor is it a valid module or filename.

Note that GHC doesn't even support filenames starting with a dash (try ghc -hello.hs), so I don't understand why the following hack even exists:

pastArgs :: String -> Bool
-- You can use -- to mark the end of the flags, in case you need to use
-- a file called -foo.hs for some reason. You almost certainly shouldn't,
-- though.
pastArgs "--" = True
pastArgs ('-':_) = False
pastArgs _       = True

• "--" is no longer overloaded. It just separates the GHC flags from the program arguments, and to pass program arguments you //have to// use "--". This is an improvement, because currently you might think that -v in runghc hello.hs -v is a GHC flag, while it is actually a program arguments (and might silently get ignored).
• --ghc-arg can be deprecated
• Your example would become: runghc hello.hs -package text-1.2.2.1

Are there any drawbacks to this approach (other than also breaking backward compatibility)?

Fwiw: currenly, your example can also be solved without --ghc-arg using: runghc -package=text-1.2.2.1 hello.hs.

Edit: hmm, this doesn't cover the case of runghc reading from stdin, and at the same time passing flags to GHC:

$ runghc -package=text-1.2.2.1
main = print "hello"
<CTRL-D>
"hello"

This approach looks clever at the first glance. But then:

• As you noted in the end - the program name is absent in the stdin case
• Usually Haskell programs (e.g. ghc hello.hs -package text) can specify options anywhere i.e. before or after the arguments. So designating before and after for different purposes could still be confusing because of the usual conventions being different.

your example can also be solved without --ghc-arg using: runghc -package=text-1.2.2.1 hello.hs.

I never thought about that. That's pretty nifty for current state of affairs. Yet another way. Big problem with having too many ways to do that same thing is discoverability and retention. I did not even know that ghc accepts arguments that way as well. I just looked into the man page, it is not mentioned. Could not find it in the users guide as well on a quick look in the Using GHC section. All of the users guide lists flags in the -package text convention, so that's what sticks. If I cannot easily find this and it is optional then it does not exist for me, it does not matter, its tribal knowledge.

Note that GHC doesn't even support filenames starting with a dash

Yeah, I had tried this earlier and wondered why do we have this if ghc does not support it, but I ignored it (maybe in future ghc might support that). Now I think we should just get rid of it to keep the code and documentation simple.

mentioned in commit d168c41a

closed

changed milestone to %8.0.2

Merged to ghc-8.0 with 2df0d759.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

reopened

I wrongly attached that commit with this bug. I am reopening it.

Trac metadata

Trac field	Value
Resolution	ResolvedFixed → Unresolved

changed milestone to %8.2.1

Bumping off to 8.2.1 since the proposed simplification won't happen for 8.0.2.

harendra, do you think you will be able to do this?

Let me try. I will need a reviewer. I guess all we need to do for now is - add deprecation warnings for what is to be removed in future and remove it from the documentation. The deprecation warnings will show on stderr. Later, at some point in time we will remove the unsupported ways/flags of invoking runghc.

Does that sound good?

Let me try. I will need a reviewer. I guess all we need to do for now is - add deprecation warnings for what is to be removed in future and remove it from the documentation. The deprecation warnings will show on stderr. Later, at some point in time we will remove the unsupported ways/flags of invoking runghc.

Sounds reasonable to me. I'll gladly review.

Trac metadata

Trac field	Value
Differential revisions	- → D2940

I think thomie's version could be made a bit more intuitive using something like

runghc [runghc flags] module|filename [--ghc-flags [GHC flags]] [-- [program args]]

For example

runghc Foo --ghc-flags -Wall -ddump-simpl -- -hi --bi

Like thomie's version, this requires the GHC flags to come after all runghc options and the module name, but it marks them out explicitly.

I think this issue should probably be addressed using the new GHC proposal process.