ghc command line arguments parsing

[Harendra Kumar]

On 19 August 2016 at 12:31, Sven Panne <svenpanne at gmail.com> wrote:

> 2016-08-18 19:59 GMT+02:00 Harendra Kumar <harendra.kumar at gmail.com>:
>
>> [...]  It only parses a flag which takes an argument. [...]
>>
>
> o_O AFAICT, this is even more non-standard and quite surprising...
>
>
>> As I explained above, I would prefer to keep this bug :-) and document it
>> especially for runghc as a better alternative to --ghc-arg=foo . [...]
>>
>
> While I partly understand your motivation, convenience is often the worst
> reason for doing something. Consistency is IMHO infinitely more valuable
> than having various inconsistent ad-hoc "convenient" shortcuts here and
> there. If you look around the tool landscape, commandline argument parsing
> is already less consistent than it should be (try e.g.
> ps/tar/unzip/df/java/git/...), and I don't think we should make this
> situation worse by adding yet another variation.
>
> As long as we have a way to pass arguments down the pipeline (as we
> obviously have), thing are fine IMHO. This situation is not much different
> from the common -Wl,foo option for GCC and friends to pass arguments to the
> linker. And to be honest: How often do you really *type* long commandlines
> compared to putting them into some kind of script?
>

Funnily consistency was my point too and not convenience. I totally agree
that consistency is more important. The end objective is less referring to
manuals and rely more on intuition and consistency. Its all about making it
easier to remember and not about typing less or more. But what I find
consistent you find it inconsistent :-) Maybe I am squinting too much to
see it that way. Let me explain it a bit.

I see each flag as a single unit including its argument. In fact command
line tools often combine the flag and value e.g. -f/path/to/ghc and -f
/path/to/ghc mean the same thing to runghc. This is usually done for a
single character flag only because it is unambiguous to parse even with
using a space separator. If we generalize this we can also allow a space in
the combined value if escaped e.g. -package foo and "-package foo" can be
considered the same thing. If we look at flags in this way they in fact
look more consistent - everything i.e. all flags start with a dash.

In fact I discovered that it works this way because I intuitively guessed
it, runghc CLI help did not have any mention of how to pass such args to
ghc. I discovered '--ghc-arg=' only later in users guide.

I would be happier with a gcc style -Wl,foo or -Xlinker way because it is
more consistent compared to how runghc passes options to ghc. runghc has
two ways of handling ghc options. Options starting with a dash are passed
even without having to use '--ghc-arg=' and if they conflict with runghc
options then we use '--' to separate the two. If a ghc option does not
start with a dash then we use '--ghc-arg'. Three different ways! too
complicated to remember or think about. As you said I would be happier with
an inconvenient to type but consistent alternative where we use
'--ghc-arg=' for everything and get rid of the other ways. Originally I was
trying to do it the other way round by getting rid of '--ghc-arg' instead.
But this perhaps sounds easier to think about. Let me know what you think.

-harendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160819/174a2f21/attachment.html>