Partager via

Detailed Release Notes & Known Issues for F# 1.0.4.2

  • Article

Detailed Release Notes & Known Issues for F# 1.0.4.2

F# 1.0.4.2 is now available at

[research.microsoft.com/downloads](https://research.microsoft.com/downloads). This is the post for the detailed release notes. A more user-friendly announcement will be placed on the front page of Don's F# Blog shortly :-)

This page will also list known issues with this release.

Overview of Changes:

1. Library naming scheme changed. The naming scheme for the F# library (fslib.dll) and the ML Compatibility library (mllib.dll) has been changed to accommodate future change. As we move forward these changes will allow you to use F# with .NET 1.0, 1.1, 2.0 Beta 1 or 2.0 Beta 2 for as long as you need to.

2. No more VSIP. The installation notes no longer suggest the use of the VSIP SDK when installing the Visual Studio mode (though you can use it if you wish).

This was based on user feedback that the VS mode is now stable enough that it is better to drop this recommendation. Read the documentation carefully about removing environment variables related to any existing VSIP installation before proceeding.

3. Subtyping Constraints and Operator Overloading Constraints. F# now includes a general mechanism to resolve constraints on type parameters.

This is used for both subtyping constraints, which arise when you call C# functions, and for operator overloading constraints. Operator overloading constraints are deliberately limited in scope to ensure all such constraints are resolved at compile-time and all code relying on these constraints is compiled with maximum efficiently. It is not expected that users will define their own overloaded operators, since .NET deliberately keeps the application of operator overloading to a minimum.

In addition, operator overloading can be turned off by redefining the (+) operator, e.g.

let (+) = Primitives.Operators.op_IntegerAddition

All existing code should continue to compile unchanged (please contact me directly if you have code that does not compile). Operators default to working on integers should no other constraints apply within the scope of the source code file. In this preliminary release some additional restrictions apply. More information is given in the README and the notes below, including a list of the limitations that apply in this preliminary release.

4. A number of bugs have been fixed. These are documented in the change list in the README-fsharp.html file.

Known Issues

VS 2005 Beta 1: devenv.exe enters a loop when running from an account other than the one used to install F#. This is due to a bug in Visual Studio, exposed by any Visual Studio plugins based on the Babel package. Workaround: Run regedit, go to and/or create a key called HKEY_CURRENT_USER\Software\Microsoft\Visual Studio\General and add the setting AllowBackgroundThreadCalls=1 if it is not there already (it will already be present for the account that you used to install F#)

VS 2003. Cannot open sample solution files in VS 2003. Workaround: open the sample project (.fsharpp) files instead.

VS 2003: When running FsVsPackageInstall.msi, it begins installation procedure but raise next error "Module C:\fsharp\bin\FsLangService.dll failed to register. HRESULT -2147024894. Contact your support personnel. [Exit Installation] [Try Again] [Continue]." Check that you set the FSHARP_TARGET_VS_VER environment variable to 7.1, as described in the installation notes

All versions: The warning "

This and other recursive references within..." appears when building some samples. These are just letting you know that the code is using mutually-referential objects (value recursion). Use --no-warn 40 to ignore these. The program will run fine.

Additional Release Notes

1. The naming scheme for the F# library (fslib.dll) and the ML Compatibility library (mllib.dll) has been changed to accommodate future change. As we move forward these changes will allow you to use F# with .NET 1.0, 1.1, 2.0 Beta 1 or 2.0 Beta 2 for as long as you need to.

This is because we would like versions of the library which can take maximal advantage of new features of future versions of the .NET platform, but would also like to support versions of the library which do not require these. Hence versions of the library that correspond to "older" versions of the .NET platform will have a version number in the name indicating the minimal .NET version required by the library. The suffix "ng" for "no-generics" is still used.

fslib10ng.dll -- F# library that relies on at most .NET 1.0.3705 constructs. This is used when compiling code for .NET 1.0 and .NET 1.1 (F# does not make use of any constructs added in .NET 1.1)

fslib.dll -- F# library that uses all the latest features of the latest version of .NET that F# supports (currently .NET 2.0 Beta 1)

You can control how you are compiling your F# code by using

fsc.exe --cli-version 1.0 ...

fsc.exe --cli-version 1.1 ...

fsc.exe --cli-version 2.0b1 ...

etc.

In the future you will see libraries such as fslib20b1.dll and fslib20b2.dll. These will let you keep using F# with .NET 2.0 Beta 1 or Beta 2 for as long as you need to.

When you compile C# code that uses F# code you should include the fslib and mllib DLLs that are appropriate for the way you compiled your F# code. Run ILDASM on your compiled F# code if needed.

3. The "no tailcall" versions of the F# library (fslib.dll) and the ML Compatibility library (mllib.dll) are no longer shipped. For example, lexers produced by the lexer generator can easily rely on tailcalls being taken, so supporting a "no tailcalls" option would only be of academic interest.

4. Subtyping Constraints and Operator Overloading Constraints. F# now includes a general mechanism to resolve constraints on type parameters.

This is used for both subtyping constraints, which arise when you call C# functions, and for operator overloading constraints. Operator overloading constraints are deliberately limited in scope to ensure all such constraints are resolved at compile-time and all code relying on these constraints is compiled with maximum efficiently.

All existing code should continue to compile unchanged, since operators default to operating on integers should no other constraints apply (please contact m directly if you have code that does not compile). In this preliminary release some restrictions apply. More information is given in the README and the notes below, including a list of the limitations that apply in this preliminary release. (Note: these features are not yet documented in the F# manual - the material below is a draft of the material that will be added)

The constraints supported are essentially the subtyping constraints that arise when calling other .NET code (e.g. "T : IComparable"). In addition, a general mechanism is included for pseudo-constraints on pseudo- type-variables. Although a powerful mechanism in principle, pseudo-constraints are really only for use in special situations such as operator overloading. Pseudo-type-variables are written "$a" and are reminiscent of a greatly simplified version of the variables found in G'Caml (see

pauillac.inria.fr/~furuse/generics/index.html), though with a different constraint system, and the G'Caml system allows generalizations that F# does not permit.

Pseudo-constraints are used for the operator overloads, e.g. you can act as if the operator "+" has all of the following types:

val (+): int -> int -> int

val (+): float -> float -> float

val (+): int64 -> int64 -> int64

and so on for all inbuilt integral and floating point types:

sbyte, byte, int16, uint16, int32, unit32,

int64, uint64, nativeint, unativeint, float, float32

The signature for (+) is actually:

val (+): $a -> $b -> $a when $a.op_Addition : ($a, $b) -> $a

The intent is that the "+" operator will be usable on any .NET type that supports the op_Addition operator. (However, in this release only the built-in types are considered to support the op_Addition operator).

Similar overloading applies to the following operators:

val (+): $a -> $b -> $a when $a.op_Addition : ($a, $b) -> $a

val (-): $a -> $b -> $a when $a.op_Subtraction : ($a, $b) -> $a

val ( * ): $a -> $b -> $a when $a.op_Multiply : ($a, $b) -> $a

val (/): $a -> $b -> $a when $a.op_Division : ($a, $b) -> $a

val (mod): $a -> $b -> $a when $a.op_Modulus : ($a, $b) -> $a

val (~-): $a -> $a when $a.op_UnaryNegation : ($a) -> $a

val (~+): $a -> $a when $a.op_UnaryPlus : ($a) -> $a

val (land): $a -> $a -> $a when $a.op_BitwiseAnd : ($a,$a) -> $a

val (lor): $a -> $a -> $a when $a.op_BitwiseOr : ($a,$a) -> $a

val (lxor): $a -> $a -> $a when $a.op_ExclusiveOr : ($a,$a) -> $a

val lnot: $a -> $a when $a.op_LogicalNot : ($a) -> $a

val (lsl): $a -> int -> $a when $a.op_LeftShift : ($a,int) -> $a

val (lsr): $a -> int -> $a when $a.op_RightShift : ($a,int) -> $a

val (asr): $a -> int -> $a when $a.op_RightShift : ($a,int) -> $a

Operators are assumed to operate on the type "int" if no other constraints apply within the scope of a source code file

Current limitations:

  • Pseudo-type-variables currently have the limitation that all code that uses them must be marked with the "inline" attribute, i.e. pseudo-constraints are implemented by template-like code expansion.
  • In this release the only pseudo-constraints that are supported are for operators on built-in types.

The operators +., *. etc. continue to be only used on 64-bit (System.Double/float) numbers. These operators will in all likelihood be deprecated in a future release, or limited to an ML compatibility mode.

5. Subtype constraints.

The README-fsharp.html file contains more information on this feature, including some current limitations. On the whole it is expected that users will not particularly notice this feature, though it substantially increases the usability of F# code that abstracts over .NET patterns. However, some library functions now have signatures that accept any arguments that satisfy a given interface. This means that F# client code, particularly F# GUI code, will no longer need to insert as many casts at call-sites.

For example, the type of Idioms.using is now

val Idioms.using: (_ :> System.IDisposable) -> (unit -> 'a) -> 'a

Read this as "Idiom.using can be used on any value that can be coerced  (upcast) to the IDisposable type." For those familiar with OCaml this is similar to writing:

val Idioms.using: #System.IDisposable -> (unit -> 'a) -> 'a

The second syntax is under consideration for an inclusion in a later release of F#.

Comments