Unfortunately I don't have any beginner tutorials to recommend, there are probably some good ones out there. http://fsharp.org/ is a good place to start; you can also look at https://fsharpforfunandprofit.com/learning-fsharp/
As to your specific problem, fsharp code can run like python does, that is, compiling it on the fly from source. It can also run in a precompiled form (as a .net assembly packaged in a .dll or .exe). <EntryPoint> is only relevant for the latter.
You could start writing your program in python style like this:
// wc.fsx open System open System.IO
let text = File.ReadAllText("sample.txt") printfn "%s" text
I didn't actually count the words because you probably want to fill that in :) Anyway, you could run this program with "fsharpi wc.fsx" on a mac or "fsi wc.fsx" on windows. If "sample.txt" does not exist it will throw an exception.
If you wanted the precompiled .net assembly form, the source would look like this:
// wc.fs open System open System.IO
[<EntryPoint>] let main argv = let text = File.ReadAllText("sample.txt") printfn "%s" text 0 // return an integer exit code
You then build that with "fsharpc wc.fs" (on a mac) or "fsc wc.fs" on windows. On windows you can run the resulting .exe directly, on a mac you need run it with mono, eg "mono wc.exe".
Fsharpi works like the the "python" command with no arguments, it starts interactive mode, you can paste code in there and see what Fsharp does with it.
It helps to have a good editor to start. Visual Studio is obviously good for windows, and Xamarin is decent for mac. I haven't extensively used any of the other editor plugins.
this page has a decent list: http://fsharp.org/guides/web/
i played a bit with Suave last summer and enjoyed it. depending on what your needs are some may be more appropriate (e.g. features or ease of getting stood up).
I would suggest following the up-to-date instructions from Microsoft here: https://docs.microsoft.com/en-us/dotnet/fsharp/
As for free books, sign up for a free trial for Safari Books Online (they won't ask for your credit card or anything just for the trial), and read this excellent book:
<whisper> when your free trial expires you can sign up with another email address </whisper>
I highly recommend dbup to slightly tighten your goose. Very low ceremony.
Seems to support Postgres: https://www.nuget.org/packages/dbup-postgresql
Suave will probably be what you're looking for:
I use it and like it, but it's not for everyone.
I wouldn't call it lacking. More like some assembly required. It has LSP support and various useful packages. You'll have all the expected things like autocomplete, go-to def, rename, autoformat, etc. You can end up with functionality quite close to IDEs like VSCode.
If you don't like spending time customizing much, I'd highly recommend Doom Emacs for a fairly seamless experience.
big fan of F# here. you can definitely learn it as a first language, although you may quickly get into the deep end. the community, however, is very friendly, much more so than many other languages.
as for resources, i like the Programming F# book out on O'Reilly a lot. i am not too keen on the APress one (black and yellow cover). a good list of books is here, including a new one covering mobile stuff in F#.
http://fsharp.org/about/learning.html
as for if it's the best choice, not knowing your background (e.g. math, science, business, the arts), one of the more common first languages to learn is python. i came to F# from python (after ~10 years), FWIW, and now prefer F# over python. you can quickly get up to speed in programming concepts and then move into other languages.
no idea myself, but you might kind of be looking in the wrong place.
I'd suggest finding some existing math libraries/projects and looking at their todos/roadmaps/etc and asking those contributors what help they need
check out the open source libraries listed here. Seems like the biggest is and most general is math.Net but it won't necessarily be pure F#, as it's primary target is all of .Net. If you want to restrict yourself to F# only though there's stuff there to work on.
Even if you'd rather stick to yourself and make your own library as an F# learning exercise, perusing the list of opensource and commercial libraries might be of benefit just so you know what's out there, both to know what areas are untackled (and might be primed for some harder to code original contributions), and which areas are well represented (for example, for times you're more interested in learning how F# works and would like to see how others answered approached the same problem), and perhaps which areas are well represented commercially but lack open source alternatives (if that happens to align with your personal vision of ideal beer)
Myself I'm new to F# and functional and despite being a programmer of some years have yet to see any way I can contribute anything not already done better by many others. Getting involved in FAKE would be awesome for me but I'm not DevOps so much in my current gig so whatev. Good luck and best wishes to your future maths and F# explorations. Have fun :)
I think that was actually for Atom editor, of which Visual Studio Code is a derivative.
I've been working off an on getting VSCode going for f# as well, and I think all we have to do is define the msbuild task in .settings/tasks.json, and then define one or more launch configurations, so you can say 'debug' and have stuff actually happen.
If you want to go at it, take a look at the documentation sections for Debugging and Tasks.
You are indeed correct.
// * Summary *
BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19041.508 (2004/?/20H1) Intel Core i7-4790K CPU 4.00GHz (Haswell), 1 CPU, 8 logical and 4 physical cores .NET Core SDK=3.1.201 [Host] : .NET Core 3.1.3 (CoreCLR 4.700.20.11803, CoreFX 4.700.20.12001), X64 RyuJIT DEBUG DefaultJob : .NET Core 3.1.3 (CoreCLR 4.700.20.11803, CoreFX 4.700.20.12001), X64 RyuJIT
| Method | Mean | Error | StdDev | |------- |---------:|----------:|----------:| | testA | 1.811 ns | 0.0071 ns | 0.0060 ns | | testB | 1.367 ns | 0.0112 ns | 0.0105 ns |
source:
// Learn more about F# at http://fsharp.org
open System open BenchmarkDotNet.Attributes open BenchmarkDotNet.Running
let sq x = x * x
// int -> int -> int let testA x value = let sqx = sq x compare value sqx
// int -> (int -> int) let testB x = let sqx = sq x fun value -> compare value sqx
let curriedA = testA 2 let curriedB = testB 2
type Bench() = class [<Benchmark>] member this.testA () = curriedA 6 |> ignore [<Benchmark>] member this.testB () = curriedB 6 |> ignore end
[<EntryPoint>] let main argv = BenchmarkRunner.Run<Bench>() |> ignore 0 // return an integer exit code
Components and hooks are not Elmish concept. Elmish only handles commands, model and view. Strictly speaking they are not "pure Elmish".
If you want to create your own react component, you first need to understand react components and hooks.
https://reactjs.org/docs/components-and-props.html
https://reactjs.org/docs/hooks-intro.html
Then you can implement your own react components using Fable.React.FunctionComponent
module. It maps pretty much 1-to-1 to react concepts.
To be fair, documentation on this is pretty sparse, but if you're familiar with React, it should be straightforward.
Well is just .NET all the way down. So is not much to wrap. Or look at this:
http://fsharp.org/guides/data-access/
--
Is important to note that what is practical or what is idiomatic is not always the same. So, DB acces is as good as with C#, or you can spice it a bit the F# way. But if time is critical, you can do that later.
This is how I start with F#.
Visual Studio Code? F# debugging support was added in June 2015 according to here
I'm a long time Arch Linux user myself, and only recently turned traitor to move to mac :) So this matters to me too.
CROSS-PLATFORM: For those of you not using Vim or Emacs, Visual studio code (https://code.visualstudio.com/) will take you further than Monodevelop, and will feel a little more comfortable. It plays well with Git, Azure and other languages besides F#/C#. It will work identically across Mac, Linux, and Windows.
@gnuvince Mono's fine to get started and will support fairly large projects. It will certainly take you past the point where you'd need to move your code onto dedicated servers anyway, in which case your desktop environment doesn't really matter anymore. We're going to have an emphasis on deploying online throughout the course (especially if we reach some of those stretch goals) and we'll show you how to manage that.
I'd say if you've got Mono and Emacs working well together, you're pretty much sorted for a lot of tasks.
The best one I've found so far has been <u>Purely Functional Data Structures</u> by Chris Okasaki. It's a bit of an academic work, but it might help you out. (I know you said algorithms, not data structures, but the algorithms tend to follow naturally from the data.)
The usual suspects, mostly to do with my new programming language (which is currently implemented in F#):
module Foo {...}
and type List(a) = Nil | Cons(a, List(a))
.I'd second the SOLID take... if one is doing OOP and doesn't practice SOLID, well... you really don't have a foundation to sell FP. But I imagine the Clean Coder might be receptive if you can show that once you take SOLID to its logical conclusion you'd end up with FP. Other than that, I'd take "it's all about trade-offs" stance, as FP practitioners often portrayed as rosy-glasses/ivory tower types. Pattern matching is incredibly powerful tool C# doesn't have, it makes certain things so much easier/shorter. Maybe find a good example, that demonstrates how properly implemented OOP alternative would end up ridiculously complicated. Highlight the trade-offs (adding a case versus extending an interface). Type inference trade-offs (limited/absent co- and contra-variance support). Options vs nulls could be interesting to explore. You'd think it's a clear win, yet there are still a lot of people who think they'd rather crash at runtime.
Regarding 'don't talk about monad', I write a blog post on bad communication habits among FP fans recently: https://medium.com/@vivainio/functional-programming-dysfunctional-communication-1320b55c957f
The type provider idea came to mind, alas it's not an easy first target for me as of now, I'm just starting to use F# more frequently and implementing advanced type providers is not something I can quickly achieve (I needed the basic "more functional" idioms usable quick so I can work on scripts).
I agree a type provider would rock and be refactoring friendly.
Discussion just began about such a type provider on the mailing list: https://groups.google.com/forum/#!topic/fsharp-opensource/G9W5Gj5o_VQ someone started such effort: https://github.com/adamchester/DocoptNetProvider
There are a couple of ways to do it. Sort of depends on what version of node OP is using, too.
https://nodejs.org/api/packages.html#packages_determining_module_system
package.json
containing "type": "module"
seems like one of the more straightforward options.
--experimental-modules
shouldn't be required anymore as of v13.2.0, though.
https://nodejs.medium.com/announcing-core-node-js-support-for-ecmascript-modules-c5d6dc29b663
As https://xyncro.tech/chiron/guides/ says, "Chiron works rather differently to most .NET JSON libraries with which you might be familiar, using neither reflection nor annotation, but instead uses a simple functional style to be very explicit about the relationship of types to JSON."
So your analysis of it being "functional programming for its own sake" is pretty much correct. I don't see that as a bad thing: it allows you to write code in the style you prefer. If you like the way Newtonsoft automatically figures out the serialization of your objects, great. There's absolutely nothing wrong with using Newtonsoft.Json; there's a good reason why it's the most-downloaded NuGet package in the world, downloaded over 5x more often than the second-place package. However, if you prefer to be explicit about your serialization, and you like the functional style of using apply
and bind
, then Chiron fills that niche. It's not an often-requested niche, but there are some people who prefer to code that way, so Chiron allows them to make that choice -- and having options available to match your preferred coding style is, overall, a good thing.
Published it. As it turns out it was not too hard with the GUI NuGet app linked in the first tutorial, so I'd recommend that if you are interested in trying yourself.
Fsharp for fun and profit as a PDF ebook:
https://www.gitbook.com/book/swlaschin/fsharpforfunandprofit/details
The Scott's new book currently in preview:
https://pragprog.com/book/swdddf/domain-modeling-made-functional
The Diagrams Manual lists all of the type classes in the library and how they're used to organize and transform the contents of the affine space.
// * Summary *
BenchmarkDotNet=v0.12.1, OS=Windows 10.0.19041.508 (2004/?/20H1) Intel Core i7-4790K CPU 4.00GHz (Haswell), 1 CPU, 8 logical and 4 physical cores .NET Core SDK=3.1.201 [Host] : .NET Core 3.1.3 (CoreCLR 4.700.20.11803, CoreFX 4.700.20.12001), X64 RyuJIT DEBUG DefaultJob : .NET Core 3.1.3 (CoreCLR 4.700.20.11803, CoreFX 4.700.20.12001), X64 RyuJIT
| Method | Mean | Error | StdDev | |------- |----------:|----------:|----------:| | testA | 0.0061 ns | 0.0039 ns | 0.0036 ns | | testB | 3.8540 ns | 0.0444 ns | 0.0393 ns |
source:
// Learn more about F# at http://fsharp.org
open System open BenchmarkDotNet.Attributes open BenchmarkDotNet.Running
let sq x = x * x
// int -> int -> int let testA x value = let sqx = sq x compare value sqx
// int -> (int -> int) let testB x = let sqx = sq x fun value -> compare value sqx
type Bench() = class [<Benchmark>] member this.testA () = testA 2 6 |> ignore [<Benchmark>] member this.testB () = testB 2 6 |> ignore end
[<EntryPoint>] let main argv = BenchmarkRunner.Run<Bench>() |> ignore 0 // return an integer exit code
You should get on the F# Slack. You need to be a member of the F# Software Foundation, but membership is free. They have a #beginners channel that's great for questions like yours.
F# is a statically typed .Net language just like C#, and F# code is instantly accessible from C#. To get started, from your C# project simply add a reference to your F# library, just as you would with a C# library. If you're designing an F# component to be consumed by multiple languages you should also check out the F# Component Design Guidelines: http://fsharp.org/specs/component-design-guidelines/
Well, bundling the dependencies is a thing, wether you like it or not I'm not here to convince you otherwise. However if bundling, versioning ensures that if your app is updated the user will use the new version (which is identified by the persistent hash) instead of whatever is in their cache and splitting cuts the download in half, assuming you update your code often but dependencies - not so much.
http://www.amazon.com/Programming-Language-Concepts-Undergraduate-Computer/dp/1447141555
This book is great. It's a book using F# where you build compilers, interpreters, etc, and learn a bunch of theory along the way. If you don't mind being a bad person, you can find a pdf through google pretty quick.
I strongly recommend the excellent Stylish F# 6: Crafting Elegant Functional Code for .NET 6 by Kit Eason. One of my all-time favorite programming books, and a total joy to read. Seriously, check out the first two pages of Chapter 1 via the "Look Inside" feature on Amazon, it gives the sell on why a style guide is important, and how style affects the substance of a program.
The book contains a fantastic reference regarding collections (and associated data structures, modules, etc) and a lot of other great advice. It also goes into detail on Railroad Oriented Programming, which I'd say is one of the more important concepts for writing idiomatic F#.
You can also check out www.fsharpforfunandprofit.com, though a lot of the articles are rather outdated.
If you really want to learn about purely functional algorithms, you could check out Pearls of Functional Algorithm Design by Richard Bird.
I actually used a service for this (IFTTT), so unfortunately there's no source code to share. Kind of a shame, I know. Building it in F# might be more work than it's worth IMO, but someone can feel free to prove me wrong and I'd be happy to use it
There is a CS101 level introduction to functional programming in F#
https://www.amazon.com/Functional-Programming-Using-Michael-Hansen/dp/1107684064
It's pretty good and I would say it's for advanced students.
I'm on Linux. F# attracts me a lot but I feel crazy when I start using ProjectScaffold suggested by F# foundations because it comes with several complicated files unrelated to F# itself such as *.sln, *.fsproj and long contents in build.fsx. That makes me have a hard time even I just want to use some libs. I just post a better approach on google groups for anyone who don't want to use it with an IDE and MS related files. https://groups.google.com/forum/?#!topic/fsharp-opensource/zTeIo5ZnGyk
Try https://www.nuget.org/packages/FSharp.HashCollections/. From the benchmarks on the project website seems to be faster than most of the persistent maps you mention (F# map, most of the fsharpx maps are also benchmarked). However I also suspect it depends on your use case.
Yes. Will be necessary some work on this. It's an OSS project, so will take some time to this support, unless some commercial necessity pushes forward.
For now the alternative is to use Dapper.Oracle
I guess you use a reflection-based library / nuget package to read those attributes. You can still do this in F#. The equivalent declaration and how to read it back using [Enums.Net](https://www.nuget.org/packages/Enums.NET/) would be:
```fsharp
#r "nuget: Enums.Net"
open System.ComponentModel
open EnumsNET
type Colors =
| [<Description("Blanched Almond")>] BlanchedAlmond = 1
| [<Description("Dark Sea Green")>] DarkSeaGreen = 2
let desc = Colors.BlanchedAlmond.AsString(EnumFormat.Description)
```
This was a nice video! I can see it being helpful for those new to web development in F#.
One thing I'd want to note is that you don't have to necessarily throw away the elmish style completely when using React's state management, just the benefit (and curse) that is the single message loop. This can be done via the Feliz.UseElmish package which lets you spawn an elmish loop inside a component via a React hook.
Also I'm not sure from how you phrased it, but Feliz is a completely separate implementation of React's API. It has a dependency on Fable.React purely to share the ReactElement
type so both libraries can interop.
I don't know if this is good practice or not, but I just have Paket installed in Windows via Chocolatey. This way, I don't have to do download Paket to each folder, and I can just start a project with paket init
.
That aside, though, I think the bigger issue is that Paket is currently the only way to ensure that you get the entire dependency chain when you reference a library in F# Interactive. They're working on #r nuget
, which will make things easier. I think that's coming in November.
> I know there is monogame but doesn't really suit my needs for the project
I guess that means no Godot engine as well? It's a fairly nice engine and the version with C# support can use F# (made easier with godot-fsharp-tools.
I've heard the immutability story isn't that great from a random Lobsters comment (https://lobste.rs/s/twdhuk/it_s_probably_time_stop_recommending#c_7vtyau), among other complaints. Also I don't think Kotlin knows what monads are.
I was definitely interested in Kotlin a year or two ago (different platform, functional types, cool name) but I don't think it's worth pursuing, at least for me. Scala seems to be the actual F# equivalent, although I do like F# syntax way more.
Working through project Euler puzzles to learn the language. I've finished number two, and am currently trying to get my solution to number 3 to use less than 2 gigs of memory. You could say my code currently has a lot of room for optimization. :-)
I've never used Fable, but I would think so. It's a .NET Core assembly. You can get the binary from NuGet.
Edit: It looks like Fable may have some special requirements that I'm not familiar with, so I really don't know if it will work.
Very good point. I think however that the elm guys are just more cautious with versioning. A new major version of elmish comes out once a year whereas a new version of elm (having breaking changes) is once every year or even two.
This is an experimental library that I've been working on recently, and I think it's finally ready for other people to take a look at. I welcome any feedback.
Algebraic effects provide a way to define and handle side-effects in functional programming. Here's a small example of an effectful program:
let program =
effect {
do! Console.writeln "What is your name?"
let! name = Console.readln
do! Console.writelnf "Hello %s" name
do! Log.writef "Name is %s" name
return name
}
NuGet package available here.
I was comparing some json libraries last year and found Utf8Json.FSharpExtensions (which uses Utf8json) faster than rapidjson. I wonder if you found correctness or usability problems with it.
I would have suggested V8.NET since it uses V8 underneath which provides lots of well tested features you might be seeking. It probably doesn't scale well though.
Usedotnet add package [package-name] --version [version]
. It's even easier if you search for the package on https://www.nuget.org/. It will even give you the full command to install the package. The add command is also used for linking project files to solution files.
You could also use Paket but I find it hard to use (especially because on linux I think you have to call paket using mono).
It's the "pattern" part of "pattern matching", and you can use it in other places outside of match
expressions, such as inlet bindings. It's also sometimes called destructuring in other languages because it can take a complex structure and reduce it to individual elements.
Let's say you have types for playing cards, something like this:
type suit = Spade | Club | Heart | Diamond type face = Num of int | Ace | King | Queen | Jack type card = suit * face
You want a function to validate your cards and avoid invalid states like (Diamond, Num 25)
, so you make a validate
function:
let validate card = match card with | (suit, Num x) when x < 2 || x > 10 -> None | (_, _) -> Some card
When you do something like this, match
attempts to destructure card
in different ways, defined by the patterns on the left, and then chooses the correct branch to execute based on which pattern correctly matches the value of card
. However, you don't have to write it this way because patterns can be used in other places, like let
bindings, so you could use a pattern in the function definition and make it clearer that you're only match
ing on the card value and the suit
portion of the pair doesn't affect the result:
let validate card = let (_,value) = card in match value with | Num x when x < 2 || x > 10 -> None | _ -> Some card
Of you can even put the pattern in the function definition itself if you prefer:
let validate (suit, value) = match value with | Num x when x < 2 || x > 10 -> None | _ -> Some (suit, value)
It's the same language feature in all cases: the pattern. You're just using it elsewhere instead of in match
, where you first encountered it.
From http://fsharp.org/specs/component-design-guidelines/ - referenced in your link:
> Do use classes to encapsulate mutable state, according to standard OO methodology.
Yikes. Why not just eliminate mutable state altogether?
For one thing, if we're going to use mutable state, why use F# in the first place?
Admittedly .Net interop usually requires mutation for side effects to take place. But I would think that you would ought to limit where that takes place in your app to a controlled area, similar to how Redux in JavaScript-land manages state changes. F# seems strikes me as a reasonable choice with this kind of architecture.
I think if you mix mutable style and immutable style together, mutation has a tendency to spread across your codebase until you lose the primary benefit of functional style, namely the greater ease with which you can reason about your code. (As well as other benefits such as safe parallelization and so on.)
The official F# website has some links to consulting companies. You can see if any of them might be able to help - http://fsharp.org/consulting/.
If not, you can also try asking on the official F# open forum - https://groups.google.com/forum/#!forum/fsharp-opensource.
Yup, it's an IDE from JetBrains. They build some of the best IDE's out there and have invented the Kotlin language (it compiles to the Jave Virtual Machine or transpiles to javascript or wasm).
If you can live with the resource usage, VSCodium is a fork of VSCode with all the nonfree bits stripped out.
You'll just need to download and install Ionide manually as a .vsix file, since the extension gallery is one of the main pieces of MS integration that were removed. Unless it's been published to OpenVsx
Can't Visual Studio Community be legally used commercially for small organizations and individuals? It seems like an organization with <= 250 PCs and <= 1 Million US in revenue annually would qualify to have up to five people using VS Community - from the bottom of the Visual Studio Community page:
​
>For organizations
>
>An unlimited number of users within an organization can use Visual Studio Community for the following scenarios: in a classroom learning environment, for academic research, or for contributing to open source projects.
>
>For all other usage scenarios:
>
>In non-enterprise organizations, up to five users can use Visual Studio Community [emphasis added by danysdragons]. In enterprise organizations (meaning those with >250 PCs or >$1 Million US Dollars in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above.
> MS took down VS2015 leaving F# users with no reliable IDE.
https://visualstudio.microsoft.com/vs/older-downloads/
Older Visual Studio downloads have always been available.
> If you need an editor without hassles, I think Atom editor is better than MonoDevelop on Linux: https://atom.io/packages/atom-fsharp
Hm.. Intriguing.. /me installs atom.
Always wanted to try it, but never had a reason to. My main requirement for a text editor is emacs-like key bindings (including mark-based selection mode) and for monodevelop I had to make a plugin for myself (https://github.com/nsf/emacskeys_md, it's crappy and fairly incomplete). As for atom, I've seen quite a few emacs emulation packages. Worth a shot.
> spacemacs
Haven't tried spacemacs - I've never been a big of a emacs, always liked vim more :)
What you could also take a look at is Visual Studio Code (https://code.visualstudio.com/) with Ionide (http://ionide.io/).
You cannot uninstall them? Just do "sudo apt remove code" and VS Code is uninstalled. I'll grant that a lot of the versions in the Debian repos are kind of old, but here's what I did to install VS Code + Ionide on Ubuntu 14.04:
If that doesn't work for you, then file a bug against whatever didn't work (Mono, VS Code, Ionide). All three of these projects want their stuff to install smoothly and easily, so if there's a major Linux distro where the installation isn't smooth, that's a bug they'll want to deal with ASAP.
That would have been the reasonable approach but that commonality wasn't captured in the business domain language. There was also the problem that these three products were nested inside of one another. ProductX
contained instances of ProductY
and there were business rules around handling that nesting. So extracting out those commonalities was difficult while maintaining those nesting rules. If I had to do it again following a similar paradigm, a common base data type and a restructuring of the nesting logic would have helped some.
What we did is re-evaluate our entire system. We found that our abstractions could not absorb change easily so we took a fresh look at how we could make it more flexible. We took the lessons we learned from <u>Righting Software</u> and captured our areas of volatility in to separate modules. It turns out what we truly need is a more generic graph-like system to manage relationships between "products" and other data.
We've written a new system using this more generic approach and it has been like day and night. We've already absorbed some pretty substantial changes with this new approach. The problem though is that we haven't reached full feature parity with the old system. So we're in the process of strangling the old system in favor of the new system. We're getting close but we would already be done if we hadn't tried to write everything in strict domain language in the first place.
> Ive been doing F# in a commercial setting since 2012 and have seen in recent years a longer gaps when sourcing contracts specific to F#.
We were doing £250k per year of F# consultancy from 2009 to 2013. I think that fell to £80k in 2017 and just £8k in 2019. We've yet to see interest at all this year.
We still use F# internally but one of those projects (Xamarin-based mobile app) was killed by the pandemic and we've had to replace all F# libraries with our own code for all the other apps.
I'm going to make us a language and tool stack that will ultimately replace our use of F# entirely...
The short "An F# rewrite of a fully refactored C# Clean Code example" article is very nice, it shows the right style for F# code. But it's unfortunate that it shows the F# code just in an image, instead of (also) regular text.
> Delimited continuations are better than undelimeted (as I have read)
I wouldn't say they are better, but they are different in small ways. Delimited continuations are more complex, but with that complexity comes a notion of scope. Depending on what you're doing, that extra capability may or may not be better (okay, so usually it's better in real programs). So if you're designing a language or library that implements continuations you still have a trade-off between the added complexity of delimited continuations vs undelimited continuations.
Have you seen Andrew Appel's book "Compiling with Continuations"? I have not read it personally, but my understanding is that it is highly relevant to your question. Perhaps you can find an online preview to see if it would help you.
I think you would benefit a lot from "wrapping up" your continuations in a computation expression. In Haskell land, they have a continuation monad and it makes writing things in terms of continuations more convenient. For instance, here is an article meant to introduce beginning Haskell programmers to the Cont monad: https://wiki.haskell.org/All_About_Monads#The_Continuation_monad
The idea is that you create a continuation at each lexical point you may want (or need) to return to (say for instance, you want to return to the top level of the interpreter when you detect a division by zero). Creating the continuation gives you the 'escape hatch' that you may call later in the exceptional case. I think the haskell example makes this clear by calling the continuations "exit1" and "exit2".
I hope that helps.
By the way, it isn't on the page yet, but Eugenia Cheng (who you may know from this: https://byorgey.wordpress.com/catsters-guide-2/ and from this: http://www.amazon.com/How-Bake-Pi-Exploration-Mathematics/dp/0465051715) will be giving a keynote.
The book I first learned from was <em>Programming F#</em> by Chris Smith (link to the most recent edition).
In the introduction, it says: >This book isn’t intended to be an introductory text on programming, and assumes familiarity with basic concepts like looping, functions, and recursion. However, no previous experience with functional programming or .NET is required.
However, I was already very familiar with C#/.NET, so I can't say how useful it would be to someone without that same foreknowledge.
You can make a small improvement here:
let split = input.Split '\n' |> Array.map int count <- split.[0] variables <- split |> Seq.skip 1 |> Seq.take count |> Seq.toList
convert to
let split = input.Split '\n' |> Array.map int |> Array.toList count <- split |> List.head variables <- split |> List.tail
head and tail of a list is an important idea commonly used in functional languages. I learned about it fromreading The Little Schemer
http://www.amazon.com/The-Little-Schemer-4th-Edition/dp/0262560992
I'm working on getting F# to work in my fresh Visual Studio 2017 install on a new machine.
Once I've got it up and running I'm going to: