<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 August 2016 at 12:31, Sven Panne <span dir="ltr"><<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">2016-08-18 19:59 GMT+02:00 Harendra Kumar <span dir="ltr"><<a href="mailto:harendra.kumar@gmail.com" target="_blank">harendra.kumar@gmail.<wbr>com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">[...]  It only parses a flag which takes an argument. [...]</div></div></div></blockquote><div><br></div><div>o_O AFAICT, this is even more non-standard and quite surprising...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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 . [...]<br></div></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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?</div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>-harendra</div></div><br></div></div>