Steven Taylor asked me to add information to the compiler guide about some of the abbreviations being used in the compiler codebase:

typar
TyparStaticReq
weird syntax:   # 61 "..\pppars.fsy"
tspec_scoref2scoref_tyvar2typ
gparams_scoref2scoref_tyvar2typ
Is g global?
celem_typ2typ
cnamedarg_typ2typ - the c in the above?
mimpl_typ2typ
ResFormatNode -  What is a ResFormat?

This page lacks any information about how to setup a project and that this is necessary in order to use Nuget.

as well as deeper explanations of the "why" of many of the functions. There are a decent amount of comments explaining the "what" of some of the functions, but not as many about how they fit how they fit into the overarching context and their purpose as a sub-component of the type checking process.

Hi,
I am not sure that this is the right place where to post this problem. I have noticed that the string comparison seems to work somehow differently than expected.

We had a couple of problems because writing string1 = string2 was returning false also if strings were equal. The only way to solve this problem is by writing string1.Equals(string2).
Is it because of what described here? Maybe the structural comparison for strings is comparing object references?

In my opinion this is a bug as it is highly non intuitive... or I am doing something wrong?

Regards,
Alessandro Seganti

Could the type inference rules used with static type parameters, inline and Generic.Zero and Generic.One be given or better documentation with examples.

This request originated from this SO question F# typing rules as inference rules in which I was hoping the answer would include the inference rules for static type parameters and inline.

I have been using F# for few years now, but every time I need static type parameters or inline or to use Generic.Zero and Generic.One with types other than numeric types I just don't feel confident in what I did.

Especially around the difference between generative and erasing providers.

Some question and notes dumped off the top of my head:

Generative providers

• Do not currently support statically provided extension methods which were added in F#4
• Do not permit direct references to generated types

Here are some things I would like clarifying:

How to add types that are generated and have root providers with static parameters.

e.g

type myType = Provider<Param="test">

There are only a few reference on this
creating-a-generative-type-provider
the-trips-and-traps-of-creating-a-generative-type-provider-in-fsharp

Both contain the basics of creating a ProvidedAssembly and adding the provided types to the ProvidedAssembly but it not clear on the correct order to avoid obscure compile failure messages.

e.g.

• Do you only add the root provider to to the provided assembly
• Do you just add the provided types generated in the DefineStaticParameters function
• Do you do this before or after adding the root provider to the namespace
• Does the order actually matter?

AddAssemblyTypesAsNestedTypesDelayed use cases

If you have another assembly which merely injects its types then you can use the AddAssemblyTypesAsNestedTypesDelayed which avoids encountering some of the above, but thats only useful if you are sending a command to an external code generator etc

When is SuppressRelocation useful?

When is ResetEnclosingType useful?

It would be good if there were canonical examples of the more common usages of generative providers, especially the areas I outlined above, as the documentation is really sparse.

https://fsharp.github.io/2015/04/18/fsharp-core-notes.html#fsharpcore-entries-in-project-files

Especially with regards to the new Sdk Projects, where there is an implicit FSharp.Core reference, no TargetFSharpCoreVersion, and BindingRedirects are no longer a thing in .Net Core world (IIRC).

Should this section remove these topics, and perhaps add some more around the implicit versions in the SDK?

The F# library guidelines from 2014 have served us fairly well. However they almost certainly now need updating to reflect changes and maturing of the F# ecosystem.

Discuss here.

cc @cartermp

Would be nice to have high-level diagram of compiler components for http://fsharp.github.io/2015/09/29/fsharp-compiler-guide.html
or processing pipeline (something like that)

I think that it will be much easier to understand with some visuals.

I'm referring to http://fsharp.org/specs/component-design-guidelines/#do-follow-the-net-guidelines-for-exceptions-including-for-f-to-f-libraries and ultimately to this thread on twitter https://twitter.com/isaac_abraham/status/596724853274710016.

What are peoples thoughts on handling "error cases" in terms of guidance? Some ideas that spring to mind that might get the discussion started: -

1. Just follow standard .NET convention. Throw exceptions for exceptional cases (although what this is is open to debate!), otherwise return types. Benefits are that this fits nicely with the typical .NET guidelines (obviously) but does not take advantage of DUs and pattern matching, nor does it make code particularly easy to reason about.
2. Return back some form of success / failure and pattern match over it. Have some form of combinator that converts an exception into a failure case, plus in conjunction with some built-in (or quickly created) active patterns you can easily match over Success or Exception (or Failure).
3. As above but use some form of computation expression e.g. Chessie in order to avoid the nesting of match clauses that typically entails.

Just to mix things up, playing as devil's advocate here I would ask - if using something like 3, the question then perhaps becomes "what are we gaining over using exceptions if a computation expression is being used as a form of premature exit, just like an exception is"?

Notes are available here: https://docs.google.com/document/d/1zAeljrLXExjWTgv2P8e69bWtX-4nB6bF5I0qNB6naas/edit

I added some preliminary notes on optimizations and a section for possible future optimizations

f331411

I did it via direct commit. Please review, then I will close this issue

The codebase is sizable and contains many conventions that are implicit to the main maintainers.

To keep codebase consistent with increasing number of contributors and help convey this currently implicit knowledge with code review, it would be great to have a short summary of:

• conventions in places
• where they apply
• design choices about code being written in such and such way
• things that prescribed / avoided
• ... whatever comes to mind of maintainers to share

We should add info on FSharp.Core and type providers here:

http://fsharp.github.io/2015/04/18/fsharp-core-notes.html

or as a separate post

https://fsharp.github.io/2015/04/18/fsharp-core-notes.html#making-pcl-portable-libraries talks about portable libraries; should it? Feels like it should talk about .Net Core libs nowadays.

I stumbled upon this paper and was curious if some of the techniques it describes could be applied to improve the speed of the F# typechecker.

Abstract
Given the sophistication of recent type systems, unification-based type-checking and inference can be a time-consuming phase of compilation—especially when union types are combined with subtyping. It is natural to consider improving performance through parallelism, but these algorithms are challenging to parallelize due to complicated control structure and difficulties representing data in a way that is both efficient and supports concurrency. We provide a solution to these problems based on the LVish approach to deterministic-by-default parallel programming. We extend LVish with a novel class of concurrent data structures: Saturating LVars, which are the first LVars to safely release memory during the object’s lifetime. Our new design allows us to achieve a parallel speedup on worst-case (exponential) inputs of traditional HindleyMilner inference, and on the Typed-Racket type-checking algorithm, which yields up an 8.46× parallel speedup on type-checking examples drawn from the Racket repository.

http://www.ccs.neu.edu/home/samth/parallel-typecheck-draft.pdf

The recent update to the open engineering guidelines suggests to use "existing second-level namespaces" for projects.

I'm considering renaming my client development libraries, but don't think there is a good fit among the existing 2nd level namespaces for this. I would like to propose deciding, as a community, on a new appropriate 2nd level namespace to add to the guidelines.

In my case, there are two libraries in question, both are geared towards client app development. One is fully cross platform today (pure PCL, intended for use with WPF, Windows Store, Xamarin Forms, etc) - the second has goals to be cross platform (supporting WPF and Xamarin Forms, so Windows Desktop, iOS, Android, Windows Phone).

The only similar project out there at the moment is @dmitry-a-morozov 's FSharp.Desktop.UI. That project is specific to WPF (Windows Desktop), and the name wasn't a community decision. In this case, I don't think "Desktop" is appropriate for my libraries in any case, as they also work on other client devices like phones.

I asked on twitter, and a few suggestions made included:

• Desktop
• Client
• UI

I personally think FSharp.Client.* makes the most sense, but would like to get other opinions, and would suggest updating the guidelines to include the new namespace once chosen.

I propose we add guidelines on naming, engineering and general advice for F# community projects and packages.

The draft is visible here: http://dsyme.github.io/2014/09/19/fsharp-libraries.html

See the pull request for a proposed draft: #13

Hello fellows,

it's time that we or rather I should start updating the whole documentation and content here as much as possible. Seeing what happened the last 2 years until now there are relevant topics which changed.

@dsyme, @ReedCopsey after talking about the future of the Core Engineering Group it's crucial to know whether it's still valid here.

It will take some time to point out what's incorrect and or missing. I'm collecting relevant information here and also ask for help if questions come up.

PS: I think of refactoring and cleanup too

Update, Todo List is provided down here:

• Delete not necessary branches
• Check build system
• Discuss further using name "Core Engineering Group"

I was talking about this with @tpetricek, @ReedCopsey and @mathias-brandewinder, and it relates to @sergey-tihon's suggestion here: #13 (comment)

The http://fsharp.github.io group has historically been called both "The F# Core Engineering Group" and "The F# Open Engineering Group". It seems it might be sensible to start thinking about splitting these aspects more carefully.

• The FSSF Core Engineering Group would be closely affiliated with the FSSF (effectively part of it) and have responsibility strictly for the core repositories and cross-platform releases of F#. The mission of the group would be specifically focused on fulfilling points 1 & 2 on the mission statement of the FSSF. They could still formulate recommendations and advice under the last bullet of the mission statement too ("Seeks to... expand the relevance and importance of F# skills and knowledge" etc.). The FSSF board (once established) would appoint one or more people (not necessarily on the board) to help guide this effort and to work with Microsoft, Xamarin, Debian etc.
• The F# Open Projects Group (or some other name) would be separate. The group would be affiliated with the FSSF just like many other groups and companies are, but either way the FSSF would seek to facilitate and support this group just like they support many other groups and companies. The group could do many things - but one thing would be to run "fsprojects", and help people to publish nuget packages and so on. They might also for example run an optional "badging" system so people can get a sense of how mature an F# package or project is - green badges for documentation, testing, completeness, stability, tutorials etc.
• The first group would publish software using the FSSF name (including the unadorned FSSF logo for F# or the name "fsharp.org"), if at all. It's possible the second group would use a different identity (fsprojects.org) or have individuals publish the packages.
• Some non-core projects not mentioned on the FSSF mission statement (such as FSharp.Charting) would likely be moved from http://github.com/fsharp (I've opened an issue on FSharp.Charting here )

I've been meaning to talk more with @sergey-tihon about this (I think he's interested in helping guide the second group and has been very active with logos already) but I thought I'd jot down the ideas here for broader feedback.

The guidance here is pretty cautious about recommending the FSharp.Core nuget package.

I'd like to understand better whether we should recommend

(a) should application writers take a dependency on this package?

(b) should library writers pushing packages containing .NET 4.x DLLs to nuget specify this as a dependency?

(c) should library writers pushing packages containing PCL DLLs to nuget specify this as a dependency?

If we recommended (b) and (c) it would be very nice to adjust the ProjectScaffold to use the package, and also to mention how to set up Nuget and/or Paket to "do the right thing".

I'm somewhat convinced that the benefit of referencing the package for libraries like Deedle, FsLab and other packages is greater than the problems that it might cause.