Re: ghc command line arguments parsing

[Harendra Kumar]

On 19 August 2016 at 14:42, Sven Panne  wrote:

>
> Hmmm, do we need '--ghc-args=' at all when we have '--' as the border
> between the 2 "argument worlds"? Without thinking too much about it, :-} I
> guess we don't. This would be consistent with how e.g. "stack exec" or
> "gdb" work. An explicit option --pass-this-to-some-progXY is only needed
> when there are more than 2 "argument worlds" involved, otherwise '--' is
> enough, and also easier to type/remember.
>

Hmm, I have been there :-) There is a slight gotcha here. This is how the
runghc command looks like:

runghc [runghc flags] [--] [GHC flags] progname [prog args]

The regular '--' separation works well when we have only two worlds; we
consume upto '--' and give the rest opaquely to the other one. Here we have
three  scopes, we need to separate runghc flags, GHC flags, program and its
args. In the above command we cannot distinguish a GHC arg from progname.

One way to solve that is to put another mandatory '--' after the GHC flags
so that GHC flags are always delimited. With that here are the valid forms
of the command:

1) runghc [runghc flags] progname [prog args]

2) runghc [runghc flags] -- progname [prog args]
3) runghc [runghc flags] -- [GHC flags] -- progname [prog args]

For simplicity we will only pass GHC args using the 3rd form of the command
even if they are not conflicting with runghc flags. Note that these changes
will be incompatible with the previous implementation. Does this sound ok?
Or we keep the good old '--ghc-arg='?

-harendra
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghc command line arguments parsing

[Sven Panne]

2016-08-19 10:58 GMT+02:00 Harendra Kumar :

> 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. [...]
>

OK, then I probably misunderstood you and we're actually in the same
boat... :-)


> [...] 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. [...]
>

Hmmm, do we need '--ghc-args=' at all when we have '--' as the border
between the 2 "argument worlds"? Without thinking too much about it, :-} I
guess we don't. This would be consistent with how e.g. "stack exec" or
"gdb" work. An explicit option --pass-this-to-some-progXY is only needed
when there are more than 2 "argument worlds" involved, otherwise '--' is
enough, and also easier to type/remember.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghc command line arguments parsing

[Harendra Kumar]

On 19 August 2016 at 12:31, Sven Panne  wrote:

> 2016-08-18 19:59 GMT+02:00 Harendra Kumar :
>
>> [...]  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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghc command line arguments parsing

[Sven Panne]

2016-08-18 19:59 GMT+02:00 Harendra Kumar :

> [...]  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?

Cheers,
   S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ghc command line arguments parsing

[Harendra Kumar]

On 18 August 2016 at 20:51, Sven Panne  wrote:

> 2016-08-17 16:37 GMT+02:00 Harendra Kumar :
>
>> ghc accepts a flag and its argument as a single quoted or escaped
>> argument as well. For example all of the following are equivalent:
>>
>> ghc -package foo
>> ghc "-package foo"
>> ghc -package\ foo
>>
>> Is this by design or accidental?
>>
>
> I would call this a bug, probably some missing quoting somewhere: Most
> commands I know don't do splitting on the arguments for themselves. Just
> try e.g.
>
>gcc "-v -v"
>

Initially I too thought the same but then I did some more testing and it
turned out that the way ghc does not really parse it exactly in the same
way as independent unquoted arguments. It only parses a flag which takes an
argument. For example:
ghc "-package foo" -- parses foo as an argument to the -package flag
ghc "-package foo -v" -- is not the same as "-package foo" and "-v"
arguments passed independently, it is "foo -v" as the argument to "-package"

So it essentially allows packing a flag and its argument together. Which
provides a nice way to pass flags and their values as a single unit. This
may be accidental to begin with but I liked this just because it makes
passing opaque flags combined with arguments from a wrapper program like
runghc much more convenient. I cannot think of any downside of this
behavior unless someone points out otherwise.


>
>> This has a nice side effect to make passing ghc arguments via rughc
>> simple. For example runghc "-package foo" or runghc -package\ foo will pass
>> "-package foo" to ghc. The alternative and documented way to achieve the
>> same effect is runghc -package --ghc-arg=foo which is not that convenient.
>>
>> My question is - can we rely on this way of parsing? If it is not by
>> design, does it make sense to legalize and therefore document this?
>>
>
> And my question is: Can we fix this bug? :-D If this is not considered a
> bug, we should be very explicit about this deviation from standard behavior
> in the documentation, including the reasons for it.
>

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 . So instead
of saying:

runghc -package --ghc-arg=text -package --ghc-arg=turtle hello.hs
We can just say:

runghc "-package text" "-package turtle" hello.hs

 -harendra
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc command line arguments parsing

[Harendra Kumar]

Hi,

ghc accepts a flag and its argument as a single quoted or escaped argument
as well. For example all of the following are equivalent:

ghc -package foo
ghc "-package foo"
ghc -package\ foo

Is this by design or accidental?

This has a nice side effect to make passing ghc arguments via rughc simple.
For example runghc "-package foo" or runghc -package\ foo will pass
"-package foo" to ghc. The alternative and documented way to achieve the
same effect is runghc -package --ghc-arg=foo which is not that convenient.

My question is - can we rely on this way of parsing? If it is not by
design, does it make sense to legalize and therefore document this?

-harendra
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs