As a C# developer I've benefited from Microsoft's Code Analysis. In F# however, Code Analysis doesn't seem to be an integrated part of the development cycle. It took me a while to enable CA on an F# project, but this blog helped. Now that I have CA enabled, it seems to produce "wrong" warnings. For instance, I have a declared a record type as
type Account = {Number : string}
for which I expect structural equality by default. This blog demonstrates that two instances of type Acccount, for which the number is the same, should be equal. Why does the code analysis then tell me that: 'Account' should define operator '!=' since it implements IComparable? For sure, had this been a C# class then I would have to jump through all those hoops, but in F# this should happen automagically.
I am applying the "Microsoft All Rules" ruleset. Do these not apply to F#, and if so, is there any ruleset that I should use?
You can also use FSharpLint in Visual F# Power Tools :
Related
It just occurred to me, that F# generics do not seem to accept constant values as "template parameters".
Suppose one wanted to create a type RangedInt such, that it behaves like an int but is guaranteed to only contain a sub-range of integer values.
A possible approach could be a discriminated union, similar to:
type RangedInt = | Valid of int | Invalid
But this is not working either, as there is no "type specific storage of the range information". And 2 RangedInt instances should be of different type, if the range differs, too.
Being still a bit C++ infested it would look similar to:
template<int low,int high>
class RangedInteger { ... };
Now the question, arising is two fold:
Did I miss something and constant values for F# generics exist?
If I did not miss that, what would be the idiomatic way to accomplish such a RangedInt<int,int> in F#?
Having found Tomas Petricek's blog about custom numeric types, the equivalent to my question for that blog article would be: What if he did not an IntegerZ5 but an IntegerZn<int> custom type family?
The language feature you're requesting is called Dependent Types, and F# doesn't have that feature.
It's not a particularly common language feature, and even Haskell (which most other Functional programming languages 'look up to') doesn't really have it.
There are languages with Dependent Types out there, but none of them I would consider mainstream. Probably the one I hear about the most is Idris.
Did I miss something and constant values for F# generics exist?
While F# has much strong type inference than other .NET languages, at its heart it is built on .NET.
And .NET generics only support a small subset of what is possible with C++ templates. All type arguments to generic types must be types, and there is no defaulting of type arguments either.
If I did not miss that, what would be the idiomatic way to accomplish such a RangedInt in F#?
It would depend on the details. Setting the limits at runtime is one possibility – this would be the usual approach in .NET. Another would be units of measure (this seems less likely to be a fit).
What if he did not an IntegerZ5 but an IntegerZn<int> custom type family?
I see two reasons:
It is an example, and avoiding generics keeps things simpler allowing focus on the point of the example.
What other underlying type would one use anyway? On contemporary systems smaller types (byte, Int16 etc.) are less efficient (unless space at runtime is the overwhelming concern); long would add size without benefit (it is only going to hold 5 possible values).
Reading sources of Array2D module, I've stumbled upon this interesting construct in implementation of many core functions, for example:
[<CompiledName("Get")>]
let get (array: 'T[,]) (n:int) (m:int) = (# "ldelem.multi 2 !0" type ('T) array n m : 'T #)
I can only assume that this is the syntax to inline CIL and is used here obviously to gain performance benefits. However, when I've tried to use this syntax in my program, I get an error:
warning FS0042: This construct is deprecated: it is only for use in the F# library
What exactly is this? Is there any detailed documentation?
I think that this has 2 purposes:
These functions compile down to exactly 1 CIL instruction which has to be encoded somewhere, so encoding at the source seems best.
It allows for some extra trickery with defining polymorphic Add functions in a high performance way which is hard with the F# type system.
You can actually use this but you have to specify the --compiling-fslib (undocumented) and --standalone flags in your code.
I've found some details in usenet archives: http://osdir.com/ml/lang.fsharp.general/2008-01/msg00009.html
Embedded IL in F# codes. Is this feature officially supported
Not really. The 99.9% purpose of this feature is for operations defined
in FSharp.Core.dll (called fslib.dll in 1.9.2.9 and before).
Historically it has been useful to allow end-users to embed IL in order
to access .NET IL functionality not accessible by F# library or
language constructs using their own embedded IL. The need for this is
becoming much more rare, indeed almost non-existent, now that the F#
library has matured a bit more. We expect this to continue to be the
case. It's even possible that we will make this a library-only feature
in the "product" version of F#, though we have not yet made a final
decision in this regard.
This was a message from Don Syme, dated January of 2008.
I'm following a language called 'elm' which is an attempt to bring a Haskel-esque syntax and FRP to Javascript. There has been some discussion here about implementing the pipeline operator from F# but the language designer has concerns about the increased cost (I assume in increased compilation time or compiler implementation complexity) over the more standard (in other FP langs at least) reverse pipeline operator (which elm already implements). Can anyone speak to this? [Feel free to post directly to that thread as well or I will paste back the best answers if no one else does].
https://groups.google.com/forum/?fromgroups=#!topic/elm-discuss/Kt0MbDyRpO4
Thanks!
In the discussion you reference, I see Evan poses two challenges:
Show me some F# project that uses it
Find some credible F# programmer talking about why it is a good idea and what costs come with it (blog post or something).
I'd answer as follows:
The forward pipe-idiom is very common in F# programming, both for stylistic (we like it) and practical (it helps type inference) reasons. Just about any F# project you'll find will use it frequently. Certainly all of my open source projects use it (Unquote, FsEye, NL found here). No doubt you'll find the same with all of the Github located F# projects including the F# compiler source itself.
Brian, a developer on the F# compiler team at Microsoft, blogged about Pipelining in F# back in 2008, a still very interesting and relevant blog which relates F# pipes to POSIX pipes. In my own estimation, there is very little cost to implementing a pipe operator. In the F# compiler, this is certainly true in every sense (it's a one-line, inline function definition).
The pipeline operator is actually incredibly simple - here is the standard definition
let inline (|>) a b = b a
Also, the . operator discussed in the thread is the reverse pipe operator in F# (<|) which enables you to eliminate some brackets.
I don't think adding pipeline operators would have a significant impact on complexity
In addition to the excellent answers already given here, I'd like to add a couple more points.
Firstly, one of the reasons why the pipeline operator is common in F# is that it helps to circumvent a shortcoming the way type inference is currently done. Specifically, if you apply an aggregate operation with a lambda function that uses OOP to a collection type inference will typically fail. For example:
Seq.map (fun z -> z.Real) zs
This fails because F# does not yet know the type of z when it encounters the property Real so it refuses to compile this code. The idiomatic fix is to use the pipeline operator:
xs |> Seq.map (fun z -> z.Real)
This is strictly uglier (IMO) but it works.
Secondly, the F# pipe operator is nice to a point but you cannot currently get the inferred type of an intermediate result. For example:
x
|> h
|> g
|> f
If there is a type error at f then the programmer will want to know the type of the value being fed into f in case the problem was actually with h or g but this is not currently possible in Visual Studio. Ironically, this was easy in OCaml with the Tuareg mode for Emacs because you could get the inferred type of any subexpression, not just an identifier.
As a follow-on to F# fsi.AddPrinter: Does AddPrinter have ability to take list apart?
I was not aware that type printers should provide for handling a list as input.
As such, are there any published standards for what is/should be required of a type printer?
Can you please provide references to examples of such code.
I was not aware that type printers should provide for handling a list as input.
I advise you not to do so. If you do it, you break KISS principle and may surprise other team members with a strange way of displaying very standard 'T list. Just provide a printer for 'T and let F# Interactive figure out the rest.
You may consider this case
type Theorem = Axiom list
where you care about Theorem and would like to display it in an appropriate way. Then it makes sense to define a printer so that a Theorem is printed out as
:- axiom 1, axiom 2, ..., axiom n.
This example isn't a very good example because you probably prefer a type-safe solution
type Theorem = Theorem of Axiom list
That said, you may ask whether you should go for fsi.AddPrinter at all. The fsi.AddPrinter bits may be there due to legacy reasons. More universal solutions are to override ToString() methods and to use StructuredFormatDisplay attribute in order that you have good printers for both fsc and fsi, which work with printf "%A", printf "%O", etc.
Why does it seem like the order of the arguments matters for F#? It doesn't matter for C# (which uses the same compilation model). When I try this:
# main.fs
module Main
let main = Printer.print_repeatedly 5 "hello, world"
# printer.fs
module Printer
let print_repeatedly n str = for x in 1..n do printfn "%s" str
And I execute the compiler (both Microsoft's and Mono's) with main.fs preceding printer.fs, I get an error:
main.fs(4,12): error FS0039: The namespace or module 'Printer' is not defined
If I do printer.fs before main.fs on the command line, it's fine. Is there a reason the compiler requires this for F#?
In F#, the order of files passed to the compiler absolutely does matter: the F# compiler reads programs strictly left-to-right and top-to-bottom. Variables and types may only refer to those defined before them, unless you explicitly indicate a mutually recursive relationship via and.
If you come from C#, this may seem like a limitation at first. But you learn that in practice it is actually an incredibly effective enforcement of code organization and prevents recursive reference madness.
Note that forward references are actually a fairly modern feature of programming languages and compilers (you don't get them for "free"), if you've ever had to work with early C++ compilers you may remember the need for forward declarations to enable this (having the compiler do the work cost memory which has not always been so abundant).