Quantum computing attracts a lot of attention from scientists and software developers.

I suggest writing a client library to run F# code on the D-Wave quantum computers in order to improve F# visibility and popularity among software developers and scientists specializing in optimization, machine learning, pattern recognition and anomaly detection, financial analysis, software/hardware verification and validation, scheduling and logistics, bioinformatics.

The world's first commercial quantum computer (D-Wave One) was built in 2010 by the D-Wave Systems Inc. (offices in Palo Alto, CA, Washington, DC, and Burnaby, British Columbia, Canada). In 2013 the D-Wave Systems Inc. shipped a 512-qubit D-Wave Two system. The D-Wave superconducting quantum computers are being used by Lockheed-Martin, Google, NASA, and USC. For example, NASA's quantum computer solved a problem 100 million times faster than a conventional computer could ( http://www.popularmechanics.com/technology/gadgets/a18475/google-nasa-d-wave-quantum-computer ). In 2015 the D-Wave Systems Inc. announced general availability of the 1000+ qubit D-Wave 2X system. In September 2016 the D-Wave Systems Inc. announced details of its most advanced quantum computing system, featuring a new 2000-qubit processor. The new processor doubles the number of qubits over the previous generation D-Wave 2X system, enabling larger problems to be solved and extending D-Wave’s significant lead over all quantum computing competitors. The new system also introduces control features that allow users to tune the quantum computational process to solve problems faster and find more diverse solutions when they exist. In early tests these new features have yielded performance improvements of up to 1000 times over the D-Wave 2X quantum computer ( http://www.dwavesys.com/press-releases/d-wave-systems-previews-2000-qubit-quantum-system ).

The D-Wave Systems Inc. is focusing on putting the quantum computers to work solving industry-scale classification, learning, and optimization problems.

Just as the classical computer world needed a software ecosystem to spur usage and development, quantum computers do as well.

The D-Wave Systems quantum computer has a web API with client libraries available for C, C++, Python and MATLAB ( http://www.dwavesys.com/software ). This interface allows THE MACHINE to be EASILY ACCESSED AS A CLOUD RESOURCE OVER A NETWORK. Using development tools and client libraries, users can write code in any language supported.

BOTTOM-LINE ISSUE: Where is a client library for F#?

I think Don Syme as an a Principal Researcher at Microsoft Research and the Microsoft F# development team (the Microsoft top management can also be asked to participate in negotiations, if needed) are able to quickly find a common language with the D-Wave Systems leadership ( http://www.dwavesys.com/our-company/leadership ), obtain source code of client libraries in C, C++ etc., open a new GitHub project and attract Microsoft and non-Microsoft (if needed) contributors, port the client library to F#, obtain network access to a quantum computer, and compile, run and test the F# client library for correctness on the real quantum machine. It would be mutually beneficial cooperation between Microsoft, D-Wave Systems Inc., and F# developers.

It may happen that such an effort would enrich F# with quantum data types, quantum programming facilities from the QCL high-level, architecture independent programming language for quantum computers ( http://www.devtopics.com/qcl-obscure-programming-language-of-the-month/ ; http://tph.tuwien.ac.at/~oemer/qcl.html ).

In any case, it would be a huge PR effort to promote F# as a modern, efficient, functional-first language for data processing on both classical and quantum computers.

http://stackoverflow.com/questions/8154730/object-expression-for-abstract-class-without-abstract-members

Object Expressions are a great feature to create instances of single-use interface / abstract class instances without polluting the namespace.

At the moment it is impossible to inherit from an abstract class which does not define any members.

If I have an abstract base class

[<AbstractClass>]
type Foo(i:int) = class end

then I would like to be able to exten it like this:

let foo = { new Foo(1) }

But this errors out with

Invalid object expression. Objects without overrides or interfaces should use the expression form 'new Type(args)' without braces.

The suggestion obviously doesn't work, since the base type is abstract.

The workaround is to define it like this:

let foo = { new Foo(1) with member __.ToString() = base.ToString() }

While it is quite trivial to write these functions, I think they have merit. First of, it is good there's a Seq.exactlyOne, but it throws and if you want a non-throwing version, you'll have to write one your own. It's odd there's a creator function, Seq.singleton, but not a test-function.

Since we have Seq.exactlyOne, it should have its logical cardinality counterparts for zero-or-one and one-or-more to be available too.

I suggest we add:
Seq.tryExactlyOne
Seq.oneOrMore (throws)
Seq.zeroOrMore (throws)
Seq.tryOneOrMore
Seq.tryZeroOrMore

The reason it is better to have these in FSharp.Core is that, if one implements these by hand, it requires at least two iterations until the 2nd element. An optimized implementation may prevent this.

See also the discussion here: http://stackoverflow.com/questions/39628567/non-throwing-version-of-seq-exactlyone-to-test-for-a-singleton-sequence

Given that F# already automatically tells you what member constraints the classes should have, why not go an extra step and have the compiler write them out implicitly like in normal let statements.

I just recently had a situation where in a class I had to explicitly write a bunch of them all out like in the following:
```
type FFRec<'state when 'state: (member Tape: Stack<unit -> unit>)
and 'state: (member Mem: ObjectPool)
and 'state: (member Str: CudaStream)
and 'state: (member Workspace: Workspace)
and 'state: (member IsInferenceOnly: bool)> =
```
This would be bad if I had a bunch of classes where for each one, I had to write out every constraint.

Of course I replaced the above with a single subtyping constraint, but is there any reason why the compiler could not have done this automatically? Also if that is not possible, would it be possible to introduce an abbreviation feature for type constraints instead of just types. They would make structural typing a lot more palatable.

Having recently been introduced to structural typing in F#, I am quite a fan of it and even the syntax which bothered me at the beginning does not look worse than anything you might find in Scala for example. I think this particular feature of the language could be a great selling point if it was made nicer.

The current indentation rules around records seem inconsistent, or at least counter-intuitive. Consider for instance:

type Foo = {
....Foo:int
....}

type Bar = {
....F:Foo
....}

let bar = {
....F = {
........Foo = 10
........}
....}

This is valid. But if you change F in Bar to VeryLongName:

type Baz = {
....VeryLongName:Foo
....}

let baz = {
....VeryLongName = {
........Foo = 10
........}
....}

We now get a warning:
warning FS0058: Possible incorrect indentation: this token is offside of context started at position (10:20). Try indenting this token further or using standard formatting conventions.

In a similar fashion, indentation rules around adding members to records seem inconsistent, or at least counter-intuitive.

The 2 examples below are valid:

type Foo1 =
....{
........data:int
....}
....member x.Data = x.data

type Foo2 = {
....data:int
....}
....with member x.Data = x.data

... but this one is not:

type Foo3 = {
....data:int
....}
....member x.Data = x.data

There is a workaround - systematically put the opening brace { on the second line - but the "shorter" syntax is quite nice, and allows to write compact and readable code. Given what is currently acceptable syntax, relaxing a bit the rules would be quite nice, and follow the principle of 'least surprise'.

Note: this is loosely related to https://fslang.uservoice.com/forums/245727-f-language/suggestions/9156844-relax-some-of-the-indentation-rules ; that specific problem is brought up in the comments.

Note: sorry about the .... but this is the only way I could find to keep the code indentation preserved.

Have TypeProviderConfig.IsHostedExecution = true for type providers instantiated in *.fsx files

This came up in my work on FSharp.Data.SqlClient library.
Up until version 1.8.2 version of the library SqlCommandProvider provided command types with two constructors of following signatures:
new: connectionString: string, ?commandTimeout: int
new: ?connection: SqlConnection, ?transaction: SqlTransactoin, ?commandTimeout: int
Keep in mind that above are not normal F# type signatures but rather signature as suggested by Intellisense otherwise parameters with default values won’t show as optional.
It allowed to write following code:
do
use cmd = new SqlCommandProvider<"SELECT 42", "Server=.;Integrated Security=true">()
cmd.Execute()
It resolves to second constructor invocation where all parameters have default value e.g. optional.
At runtime this code reuses design time connection string to connect to a database. This is typical coding style for F# scripting (*.fsx + FSI).
For production-like scenarios connection string is read from some sort of configuration.
One way to archived that is to use connection string name from config file app.config/web.config. In that case type provider reads connection string from config file both at design time and runtime which allows to have different connection string at runtime by overriding *.config file
Pattern #1
do
use cmd = new SqlCommandProvider<"SELECT 42", " name=AdventureWorks">()
cmd.Execute()

app.config
<configuration>
<connectionStrings>
<add name="AdventureWorks" connectionString="Data Source=.;Initial Catalog=AdventureWorks2012;Integrated Security=True" />
</connectionStrings>

…

Pattern #2
The other way is override connection string or connection object at runtime
type Get42 = SqlCommandProvider<"select 42", "server=.;trusted_connection=yes">
…
Do
let connStr = readConnectionStringFromConfig()
use cmd = new SqlCommandProvider<"SELECT 42", "Server=.;Integrated Security=true">( connStr)
cmd.Execute()

Note that will resolve to invocation of first constructor.
That how it worked until 1.8.2
I got a complaint from one of the library users - Jet.com. They use pattern #2. They said the biggest source of mistakes is that developers forget to provide runtime override for connection string and it fails at runtime.
An issue was opened to reflect that
https://github.com/fsprojects/FSharp.Data.SqlClient/issues/195
And it was fixed and deployed as part of 1.8.2
To sum up the change is following: if literal connection string was used at design time, at runtime either connection string or connection object is mandatory parameter. I believe it was right change to support production quality code but it made scripting counterpart ugly and I actually received complaints from customers.

[<Literal>]
let connection = "Server=.;Integrated Security=true"
do
use cmd = new SqlCommandProvider<"SELECT 42", connection>(connection)
//connection mentioned twice. Not elegant
cmd.Execute()

It would be nice if the type provider can generate slightly different constructor signature for scripting e.g. allowing to create provided command with parameter-less ctor invocation.
I already do something similar in response to
https://github.com/fsprojects/FSharp.Data.SqlClient/issues/185

It relies on IsHostedExecution property TypeProviderConfig
https://github.com/fsprojects/FSharp.Data.SqlClient/blob/v1.8.1/src/SqlClient/Configuration.fs#L67

But it works only when a type generated within FSI. This was enough to resolve issue 185 but not sufficient to generated diff ctors signatures.

Here is my proposal:
*.fsx files mostly meant to be executed from FSI. Why not to have TypeProviderConfig.IsHostedExecution = true for type providers instantiated in *.fsx files
So type provider will able to generate diff types depending on IsHostedExecution value

This is an alternative to: https://fslang.uservoice.com/forums/245727-f-language/suggestions/15257796-remove-warning-for-new-keyword-on-idisposable

The idea is that the new keyword provides valuable information, but only if you do not use it on all types.

When avoiding its usage, you get a visual clue as to instances of disposable types, as well as warnings if you bind them.

By making it a warning to use new unnecessarily, the compiler would effectively enforce a "best practice" with regards to IDisposable usage. It goes a long way today, but requires discipline to make it useful.

This would be especially helpful to people coming to F# from C#, as many immediately use new everywhere, and don't see this very nice safety benefit provided by the compiler.