1

Closed

fsi/fsharpi doesn't respect #nowarn 62

description

#!/usr/bin/env fsharpi
#light "off"
#nowarn "9" "51" "62";;

let _ = printfn "hi"
results in:
arch-vm[168]:~% ./test.fsx

/home/mdl/test.fsx(2,1): warning FS0062: This construct is for ML compatibility. Consider using a file with extension '.ml' or '.mli' instead. You can disable this warning by using '--mlcompatibility' or '--nowarn:62'.
hi
Due to the limitations and inconsistencies with regard to how #! is handled by different operating systems, this needs to be fixed in fsi itself.
Closed Jan 27, 2015 at 7:11 PM by KevinRansom
Manage on github

comments

dsyme wrote Oct 23, 2014 at 10:37 AM

FWIW this only affects warning 62 for #light "off".

Have you tried using

!/usr/bin/env fsharpi --nowarn:62

drvink wrote Oct 23, 2014 at 11:07 AM

That doesn't work, because Linux actually passes the arguments like this:

argv[0] = /usr/bin/env
argv[1] = fsharpi --nowarn:62

Crazy, but true--so env ends up tries to execute "fsharpi --nowarn:62", which of course fails.

dsyme wrote Oct 23, 2014 at 6:18 PM

Is there any specific reason you need to use #light "off"?

AFAIK almost all F# code these days is with the indentation-aware syntax, and that applies particularly to F# scripts. And as indicated in the message, #light "off" is for "ML compatibility".... I think it's fair to say that the F# scripting programming model is sufficiently different from OCaml ML programming that our recommendation would be to switch to indentation-aware syntax.

Note the problem only applies to warning 62, which is produced earlier than other warnings based on the first non-shebang line of the file.

drvink wrote Oct 24, 2014 at 11:33 AM

I use #light "off" in all of my code. I find the light syntax to be cumbersome and difficult to use. With the traditional syntax, I don't need to concern myself with formatting while I'm writing something; I can simply write what's in my head, no matter how complicated, know that it at least typechecks, and then clean it up, instead of being constantly interrupted by having to lift the nested pieces out into smaller expressions as I go. The light syntax actively interferes with and complicates writing code because it forces the user to simultaneously deal with its formatting. With light, the only way you can "just write something" is to write a very long line, otherwise you risk formatting it incorrectly.

I tried to deal with light. I really did. The tipping point was a day where I spent at least 20 minutes trying to get a complicated AST-building expression to work in something I was writing. It was like playing whack-a-mole--too difficult to tell which errors were from typechecking and which were from indentation as I was trying to fix it. I disabled light, was able to fix it immediately, and decided I'd had enough. The F# users I know (grumpy FP folks like me :)) have all done the same, if only because light makes it difficult to keep code from marching past the 80 column mark. We have big, wide monitors these days, but it's nice to have room to put documentation or other code windows next to the one you're working in!

I hope this doesn't come across as an accusation. I really appreciate the ability to turn light off. I hope the option is not removed! But it would be nice to not get the warning every time I run an F# script.

forki wrote Oct 24, 2014 at 12:05 PM

wow.

I don't want to start tabs/spaces flame wars, but all the people I know are using light syntax and nobody cares about light off. I wonder what code you are writing.

anyways it's interesting to hear that people still use (and even prefer) it.

dsyme wrote Oct 24, 2014 at 12:51 PM

Yes, it's useful feedback, thanks.

If you have any public links to some of your code, please send them along if you can. I assume you're using Visual Studio, but if not please let us know what editor environment you are using.

Thanks!
Don

drvink wrote Oct 24, 2014 at 2:43 PM

Thanks, Don! I'll mail you some code in a bit.

(I use spaces, by the way--forki's comment confuses me!)

KevinRansom wrote Oct 24, 2014 at 11:21 PM

@drvink,

Hi, I'm afraid I don't have access to any unix boxes so I may not have understood correctly, however, there is one thing about this report confuses me somewhat and that is that fsi picks up it's arguments using
Environment.GetCommandLineArgs() which returns an array of strings.

using code similar to this:
let MainMain (argv:string[]) =  
     ignore argv 
     let argv = System.Environment.GetCommandLineArgs() 
Here is the .net framework documentation for this Api: http://msdn.microsoft.com/en-us/library/system.environment.getcommandlineargs(v=vs.110).aspx
The first element in the array contains the file name of the executing program. If the file name is not available, the first element is equal to String.Empty. The remaining elements contain any additional tokens entered on the command line.

The program file name can, but is not required to, include path information.

Command line arguments are delimited by spaces. You can use double quotation marks (") to include spaces within an argument. The single quotation mark ('), however, does not provide this functionality. 
If this Api returns arguments that are incorrect then I would imagine it is a bug in mono. Perhaps this Api needs to be modified to be aware of the possibility that the OS loader can supply arguments that are not correctly space delimited.

Did I understand the issue correctly? and does my suggestion make sense?

Thanks

Kevin

latkin wrote Oct 25, 2014 at 12:34 AM

That is a standard behavior on Linux if you are using env to avoid using a full path to fsharpi.

http://en.wikipedia.org/wiki/Shebang_(Unix)#Portability
"Some systems, including Linux, do not split up the arguments; for example, when running the script with the first line like,
#!/usr/bin/env python -c That is, "python -c" will be passed as one argument to /usr/bin/env, rather than two arguments."

You could avoid it by not using "env" at all and instead specifying the full path to fsharpi, but of course that's less likely to be constant across machines.

latkin wrote Nov 26, 2014 at 1:20 AM

Updated the title to reflect the limited scope of this issue