<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.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><br></div><div>Cheers,</div><div>   S.</div></div>