F# kit

F# kit is the stress-free solution to F# Scripting in Unity.
If you can't wait for official support, then this kit is for you!
(F# kit on the Asset Store) (Vote for native support)

Features:
* Automatically compiles F# Scripts.
* Brings functional programming to Unity.
* Works with Windows and Mac Unity Editor
* Adds "Create F# Script" option.
* Generates .sln file for MonoDevelop/Xamarin/Visual Studio
* Includes examples to learn how to use it with Unity.

Screenshots:

The F# kit Window.


A simple MonoBehaviour Script.


More syntax examples.

Usage Guide:
1. Right click in the Project Area, select Create->F# Script.
2. Open and modify it.
3. Wait for F# kit to rebuild.
4. Select your GameObject, click Add Component->Scripts to add it.

Note: F# kit may show you a few download links for missing components that are necessary to compile F# Scripts (like Xamarin).

Further Reading:
* F# Cheatsheet

Roadmap:

• V1.0 [released 2016-06-15]
  • First version with Windows and Mac support
  • Hello World example
• V1.1 [released 2016-06-20]
  • Arkanoid Game example
• V1.2 [released 2016-09-12]
  • Upgrade to 5.4
    
  • OSX UnityEngine.dll path different for Unity 5.4 or newer
    
  • Create->F# Script now creates it in the selected folder
• V1.3 [released 2017-06-16]
  • Upgraded to Unity 5.6.1p1
  • Added F# kit logo to GUI
  • Removed unecessary ")" in help box
  • Save and load settings
  • Improved overall Syntax
  • .sln and .fsproj files are now created above the Assets folder next to the default .sln
  • .sln and .fsproj are not deleted anymore
  • Readme improved
  • AssemblyInfo.fs comments removed
  • Required paths are now visible and modifiable in the GUI
  • Required path status flags improved
• V1.4 [released 2017-06-27]
  • Create->F# Script uses native method now
• V1.5 [released 2018-02-06]
  • Fixed 2017.1 (or newer) ClearConsole bug

Future:
* Add more usage examples as we figure out the Unity F# best practices
* Add a simple game example
* Use Unity's Xamarin version as soon as it ships with it (Unity announced that a while ago)
* Hope for native support.

 

can it support a runtime compiler? meaning the player writing F# code in-game and pressing a gui button and running that code?

 

How do you determine build order for the script files? Or are they not allowed to reference each other?

 

What is the benefit of f#? Why a new language!?!?!?

 

Because we can.

More seriously, F# is better at certain things, C# is better at different things.

I happen to love F#, and prefer it to C# for logic.

What I gain with F#

• It forces me to expel nulls from my logic
• It is easier for me to refactor and test
• Combining/Dealing with functions is much easier
• Deferred Execution of functions
• Easy Caching for pure functions (Memoization)
• Seriously for caching I add 1 line of code and it's done

Overall, I'm not very good with F# yet. But these things are what drew me in. Other features of functional programming while nice, didn't entice me away from C# which I've been using since v1, but these things are why I love it.

 

Progress Info: submitted V1.1 the other day. It will contain a simple Arkanoid game example written in F#.

Not really. Might be possible, but I am not really interested in that feature. F# kit is supposed to be as close to native F# support in Unity as possible, and nothing fancy.

Do you mean for the F# script files? I haven't tried that in F#, but in C# the build order doesn't matter, all scripts can reference each other. My guess is that it's the same in F#.

 

Exciting -- thanks for doing this -- look forward to trying it out.

 

From your screenshot, seems like you need to install Mono and Xamarin Studio -- does doing so affect Unity's native C# support at all? Love to try this but want to make sure F# scripts and associated Mono/Xamarin support needed for them are isolated -- i.e. won't screw up or affect in any way existing/normal C# stuff

 

You are welcome. You can try it already, it's released for a few days now.

You install them separately. Unity's stuff is not touched at all. Some day Unity will probably ship with Xamarin, so then those extra tools won't be needed anymore.

 

Progress Info: working on more F# examples for the project. V1.2 will have a few functional programming functions. It's amazing that this stuff runs in Unity now.

 

Update: V1.1 is now on the Asset Store! It includes an arkanoid game example.

 

C# and F# are different in that regard. In F# the build order matters because it's a 1 pass compile as opposed to the multipass that C# does. So things later in the file/build process are completely unknown. The project file for an F# project it primarily for defining the build order of the files.

In my F# solutions I have to keep the files in order, or it won't build. However, depending on how you use it it might not be an issue. The example you gave, for instance, does reference anything from another file so it would be fine. In general it might not be a large issue. I'd just be worried because I keep building modules them composing them to build the "Engine".

 

Can you give me a simple example that causes this error? Then I can try it with F# kit. I do throw all script file names into an xml file before compiling, so perhaps modifying that order solves it.

 

Update: F# kit is now on the Asset Store for $10!

 

Are you working on Linux support for it?

 

I will if enough people request it.

 

Hello! I can not create f# file. unity version: 5.4
when click: create => f# script.
result: nothing/empty.
no error, no message
p.s i import f# kit in root of folder Assets

 

Hey,
which operating system do you use? And can you take a look at the Editor folder and FSharpBuildWindows/OSX and see if the paths in the code match the paths on your computer. If not, which paths are different?

 

os : windows 10.
on my computer all paths in script FSharpBuildWindows - correct.
i reimport asset.
now, i when click: create => f# script
result: NewBehaviourScript.fs appear in root folder.
this script i can attach to gameobject in scene and when i modify this script - success too.
but!
when i rename this script i can not attach script to gameobject in scene.
screenshot: (after drag script to folder F#Out and rename from NewBehaviourScript to test)

 

Sounds good. Yes, the class name and the file name need to be identical to be able to add it to GameObjects. So if you want to rename it to test, you also have to open test.fs and rename the class to test.

 

thanks! good.
appear in root folder. - its default behavior ? (it is possible appear in other folder ?) where i click create script ?

 

Thanks for letting me know. I submitted a new V1.2 to the Asset Store for review, which fixes your issue.

If you can't wait, open F#kit/Editor/FSharpKit.cs, find the Create function and change File.WriteAllText code to:

Code (CSharp):

1. File.WriteAllText(AssetDatabase.GetAssetPath(Selection.activeObject) + "/NewBehaviourScript.fs", content);

 

Since it wasn't mentioned anywhere. I take it that there is no debugging support?

 

Fun tool - thanks!

Bug Report:
After installing the dependencies, the first thing I did was right-click on a folder in the Project pane to create an F# script. This throws an error because it tries to create c:/NewBehaviourScript.fs

Right-clicking on the right half of the Project pane works as expected though.

 

I suggest using Debug.Log or print for now. There is a .dll that is being built after compiling the F# scripts. Perhaps your IDE can attach to it, I haven't tried that though.

Thanks for letting me know. Do you use the latest F# kit version? I did change that part of the code in V1.2.
Which OS do you use?

 

Thanks for the suggestion. I will see what I can do.

At least I know that the Visual Studio Tools for Unity do support F# debugging. I guess it won't make a difference which version, the plug-in version or the native version of VS for Unity. The FSharp.org website mentions that there is support, but the link there is for the plug-in version, not the native version.

I think Ideal solution would be if one could make Unity to create a VS solution that simply holds an F# project, too. Doesn't sound complex to me. But I guess without the source of Unity this may not be possible? Or is the VS Tool itself creating the VS solution files? Because if the tool does that, then it may be a matter of speaking with M$ to implement F# into Unity, not Unity Tekonologee.

 

I am not too worried about VS integration right now, since native F# support is probably coming to Unity sooner or later. The first goal was to be able to automatically compile F# scripts in Unity, so at least we have the option to work with it.

 

So, for me lacking VS integration is a pretty big deal. I like working in a basic text editor most of the time. But with Unity you're going to have to tear my Code Completion from my cold dead hands.

Fortunately, once you figure out the trick for it, it's not all that hard to setup a VS solution for Unity F#. But there are a lot of steps to do it. Here's how I'm doing it right now:

1. Create your unity project with F# Kit added in the Assets folder.
2. Create a new F# file by right clicking where you want it and select Create > F# Script.
   
3. Rename it if you want to, remember that you need to rename the class in the file.
   
4. Double click it to open it in Visual Studio.
5. Open "Tools > Extensions and Updates" and make sure you have "Visual F# Power Tools" installed.
6. Click Close
   
7. Open "Tools > Options > Tools For Unity" And set "Miscellaneous > Access to project properties" to True (You only have to do this the first time you setup a project)
8. Sill in Options, open "F# Power Tools" and check off "Folder Organization"
   
9. Click OK
   
10. Open "View > Solution Explorer"
11. Right click Solution then "Add > New Project..."
12. Select "Visual F# > Library"
13. Set Name to "<your unity project name>Fsharp" just to match the equivalent in C#.
14. Set Location to the base folder of your project.
15. Click Ok
16. Select "File > Save All"
17. Navigate to "<Your Unity Project>/<Your Project Name>Fsharp"
    
18. Save the solution with "<Your Project Name>Fsharp" again just for consistency.
19. Now close Visual Studio, it should close without asking you to save.
20. In your Unity project folder there is now a folder "<Your Project Name>Fsharp", open it and copy all of it's contents into your Unity project folder.
21. Delete the "<Your Project>Fsharp" folder
    
22. Open up "<Your Project Directory>/Library"
23. Create a directory named "UnityAssemblies"
24. At this point in theory you could create UnityAssemblies from scratch, but the easiest thing to do is to grab the files you need from an existing Unity C# project. From the same directory in that project you'll want the .dll and .xml file for UnityEngine, UnityEditor, UnityEngine.UI, Mono.Cecil. You can add more as you need them. Copy those into your F# project's UnityAssemblies folder.
25. In your project folder, open Visual Studio again by double clicking the "<Your Project>Fsharp" solution file.
    
26. In References right click and remove "System.Numerics"
27. Right click on References and select "Add Reference..."
28. Click Browse..., navigate to your F# project's UnityAssemblies folder and select all of the dll's.
29. Click "Add"
30. Click "Ok"
31. Under the project in VS, right click "Library1.fs" and "Script.fsx" and Delete them. (This just keeps things neat)
32. Right click on your Project and select "F# Power Tools > New Folder"
33. Enter "Assets"
34. Click Ok
    
35. Right click on the "Assets" folder in the Solution manager, select "Add > Existing Item..." and find and select the F# file you created at the start.
36. Now, double click on the file in the Solutions manager.

So now, you should be able to click on your F# file in the solution, and it won't look like UnityEngine etc are broken and Code Completion will work correctly.

When you want to open your solution you'll need to double click your F# solutionfile like you did in step 25, and will most likely have to add each file to the solution individually like you do in step 35. It's not elegant, but it will work. Obviously most if not all of this can be simplified considerably by adding it as a feature to the Asset.

I'd be grateful to anyone who runs through these steps and lets me know if they can be improved.

-Frank B.

 

Alright, for the next bit of fun.

What I have above makes it possible to access Unity dll's through the references. Does anyone have advice on how to reference .cs files from inside the f# project?

The specific use case is I'm trying to use an existing asset in my f# project.

-Frank B.

 

This might be difficult, seeing how it's not even that easy to use Javascript and C# scripts together.

 

For doing real work in Unity, this is more than a little important. Nobody in their right mind wants to reinvent the wheel, so working with existing assets is a must. Especially if you're a solo developer.

Ugly hacks to the rescue again.

Alright, so I don't know a way to get it to read C# files, but I know for a fact that it can work with DLL's that were compiled from a C# file. Here's how to make one from your assets.

1. Create a new Unity project, and put only the asset or assets that you want access to in it.
2. These assets generally come with code examples, pick one it doesn't matter which and double click on it to open Visual Studio.
3. Under solutions there will be a project named <your project name>.CSharp, right click it.
4. Click Build
5. Once it's complete then open the folder <your project directory>/Temp/UnityVS_bin/Debug/
6. There, if all has gone well, you'll find "Assembly-CSharp.dll" which contains the libraries from your project.
7. Copy Assembly-CSharp.dll into <Your F# Project Directory>/Library/UnityAssemblies/
8. Then add that dll into your FSharp project the same way described in steps 25-30 from the How to Use FSharp walkthrough.

As before, obviously these steps are messy, and inefficient. I'm sure there are better developers out there than me who can come up with a better solution, but this is the one I'm using today and I hope it helps someone else.

For anyone doing this, good luck, let me know how it went. I'm also fkberthold on the unitydev slack if you want to get in touch.

-Frank B.

 

Adding Assembly-CSharp.dll is actually a good idea. Let me know how that works out for you. I might add it to the F# kit includes later too.

 

• Code noise reduction: F# source is always shorter than C#.
• Immutable by default: This makes the code threadsafe. Now that we are on the verge of moving to 4+ core CPUs. Multithreading, so more processing power, is a very good thing for managed programming languages.

Yeah, I saw that F# vs C++ benchmark, where F# turnout to be 1 second FASTER then C++. No, I don't really understand why. But if I looked into the future like some already did, then F# may receive more auto generated threading than C# or C++. If true, this would make F# a superior language without any doubt.

 

Even if it was 1s slower than C++. The elegance is just worth it. I really wish that F# would be the default scripting language for Unity. C# works really well, but it's just so ugly and far from elegant.

I like your signature by the way.

 

Is there a specific reason why F# Kit deletes the FSharp project files? Because it seem to work fine without deleting it. And using the FSharp project itself, fixes the reference problems (open UnityEngine, etc.). I now work directly with VS and just add/sort the source files there. Took me only to comment out CleanBuild() after refactoring all project deletion code into it.

Thanks! I take it that you are referring to the source code part.

Well, I raised hell in the UE4 forums, bashing C++ and BP visual scripting because of the lack of scripting. I even left UE4 and came crawling back to Unity because of that. Funnily, UE4 is now the only engine without text based scripting.

• Stringray got Lua and Flow (visual scripting).
• CryEngine got C# and *I forgot its name. It's visual scripting, too*.
• Unity got Java-not-so-Java-Script, and C#.
• Xenko is full C# engine in the first place. Wat?

 

The project files are deleted to keep it as simple as possible. I just didn't want people to worry about them. In the future it might make sense to keep them though, and move them to where the other .sln file is.

Yes it's just so obvious. All those game engines have the fastest graphics, the greatest shaders, easiest navigation, great networking. And the most important part, the programming language, is just average at best.

 

Xamarin is working on C# AND F# support for UE4. Frankly, I hate Unity Teconologee. But Unity's community and some of the extensions on the asset store would make even UE4 blush!

 

Have you ever used C# outside of Unity? Because Unity only uses the outdate 2.0 (If I recall), and not the latest 6.0. C# 7.0 is going to support local functions!

I tried Xenko for the second time ever. And found that aside for better Xenko Editor itself, the C# is also 6.0 and got all that async jazz in it. Xenko means business, and is worth a look! I haven't tried yet to use F# with Xenko, though.

 

Sounds good, let's hope they add it soon.

 

Great News: F# kit V1.3 was submitted for review:
V1.3

• Upgraded to Unity 5.6.1p1
• Added F# kit logo to GUI
• Removed unecessary ")" in help box
• Save and load settings
• Improved overall Syntax
• .sln and .fsproj files are now created above the Assets folder next to the default .sln
• .sln and .fsproj are not deleted anymore
• Readme improved
• AssemblyInfo.fs comments removed
• Required paths are now visible and modifiable in the GUI
• Required path status flags improved

 

Update: F# kit V1.3 is now on the Asset Store!

In case of questions or suggestions, please let me know.

 

Progress: V1.4 was submitted for review. The Create->F# Script option now uses the 'native' method that allows us to name the created Script immediately.

This was the last feature on my ToDo list for now. F# runs really very well at this point!

 

@vis2k will your latest version work on Unity 5.4.1 or 5.5? I see that it can be used with Unity 5.6 but what about more older versions?

Thanks!

 

Yes, should work fine. It doesn't really use any of the newer Unity features.

 

Just bought this to try using F# with Unity 2017.1 and .Net 4.6.

When using .Net 4.6 I get this error over 999 times in my project:

Assets/Plug-ins/neuecc/UniRx/Scripts/InternalUtil/ListObserver.cs(7,36): error CS0433: The imported type `System.IObserver<T>' is defined multiple times

So I downgraded to .Net 3.5, which makes those errors go away, but it still doesn't seem to work with Unity 2017.1. All the required tools in the F# Kit window are "Good", but the .fs files I create in the project are not valid MonoBehaviours. (i.e. they don't get compiled automatically and can't be added to GameObjects)

In Visual Studio Code I get this error:

file: '.../Assets/Scripts/Test.fs'
severity: 'Error'
message: 'The namespace or module 'UnityEngine' is not defined.'
at: '2,6'
source: ''

I think that means F# Kit is failing to produce correct solution files, but I may be wrong about that.

Ultimately I'm okay with using .Net 3.5 for now, because it's still a beta feature, but I'm stuck using Unity 2017.1. Any help would be appreciated.

Is there something I'm missing? Or is this an issue of being incompatible with both Unity 2017.1 and .Net 4.6?

Truth be told, I'm excited about using F# with .Net 4.6, since so many of the tools I need for this project require .Net 4.6 already and have F# bindings.

 

Will look into it. Might be easiest if you use Unity 5.6 version until then.

 

Tried F# kit with Unity 2017.1.0p1 today and it works fine with .Net 3.5 and .Net 4.6. I recommend using 2017.1.0p1.

 

Glad to see such a recent post! I am thoroughly excited at learning reactive functional programming with UniRx and F# together! Gotta love .NET

 

Update: upgraded F# kit to the latest Unity versions (2017.1 and newer).

V1.5

• Fixed 2017.1 (or newer) ClearConsole bug

 

Thanks for this kit. Definitely the most fun way to learn F#, was easy to install and it's almost invisible while developing. Using Visual Studio 2017 and everything works as it should.