DEV Community: André Slupik

ReScript is not there yet

André Slupik — Wed, 02 Oct 2024 05:58:16 +0000

As a fan of ML-inspired languages, I always found ReScript intriguing. With async-await now recently added to the language, is it time for ReScript to shine?

It sure looks enticing:

... you can pick up ReScript and access the vast JavaScript ecosystem and tooling as if you've known ReScript for a long time¹

Doesn't force you to search for pre-made binding libraries made by others. ReScript doesn't need the equivalent of TypeScript's DefinitelyTyped.²

What's the goal of this project?
We aim to provide the best typed language experience for the JavaScript platform.³

Wow, so they provide the best typed language experience for the JavaScript platform, all without the need for pre-made bindings! Let's give it a go!

We quickly hit a wall as we attempt to do the most basic thing possible:

Hmm.. why is getElementById not on document? What's the type of document?

This picture is all the ReScript documentation has to say about it. No definition of Dom.document. F12 leads us down a chain of empty type definitions, so Dom.document does look like a simple alias for the JS document, nothing more.

Wait, so I do need pre-made bindings? What happened to "Doesn't force you to search for pre-made binding libraries made by others"?

Enter the rescript-webapi npm package, Bindings to the DOM and other browser-specific web APIs.. I follow the instructions and compiler errors, including one telling me I might have a configuration issue in "bsconfig.json", even though this file is now called "rescript.json". I get that working eventually.

Here's how it looks:

let elem = document->Document.getElementById("id")
// For the uninitiated, -> is the pipe operator.
// a->foo means foo(a)
// a->foo(b) means foo(a, b)
// The above code is therefore equivalent to
let elem = Document.getElementById(document, "id")

You'll notice that document. will bring up no code completion, as it's still basically untyped. I have to know what module and module function to call.

So the IDE won't help me type the right thing, but will it give me good information about the function I'm calling? Not really:

For reference, here's TypeScript out of the box:

Informative error, link to examples, detailed type definition. Thank you. This saves me time, effort, teaches me right as I type - this is one of the main reasons I like static typing. I'm just not getting this with ReScript.

If interacting with the DOM - the reason why JavaScript was created - is not deemed important enough to warrant built-in bindings, I think I've seen enough.

Is ReScript ready in 2024? No. Its official documentation makes lofty promises that seem outright misleading. I guess ReScript can be useful if you will write a lot of ReScript code that mostly interacts with other ReScript code. But one cannot simply ignore "the vast JavaScript ecosystem". Imagine F# without support for the BCL. Luckily, F# and its tooling were designed to consume C# types and documentation seamlessly. Surely there must be a way to leverage DefinitelyTyped in ReScript. Until ReScript does this, I don't think it can seriously compete with TypeScript.

Discriminated unions in 2024

André Slupik — Wed, 18 Sep 2024 08:56:40 +0000

Here are some slightly edited notes I took while researching a solution for discriminated unions in C#. I assume the reader is familiar with discriminated unions, wants to use them, has summarily searched Google and StackOverflow already, and is looking for more information beyond the basics.

What about OneOf?

OneOf is implemented as a non-overlapping struct so

❌ It can grow large in size.
❌ It introduces value semantics complications: default instances, mutations, copying and passing by reference.
❌ Plus, it's not serializable; an unrelated library does that, but forces me to take a dependency on Newtonsoft.Json.

Can we do better?

I experimented with a modernized version of what I was doing circa 2014: a generic base class with subclasses for each case, where Match is a virtual method, e.g.

abstract record Union<T0, T1>
{
    public abstract T Match<T>(Func<T0, T> func0, Func<T1, T> func1);

    public record Case0(T0 Value) : Union<T0, T1>
    {
        public override T Match<T>(Func<T0, T> func0, Func<T1, T> func1) => 
            func0(Value);
    }

    public record Case1(T1 Value) : Union<T0, T1>
    {
        public override T Match<T>(Func<T0, T> func0, Func<T1, T> func1) => 
            func1(Value);
    }
}

While this approach eliminates value type concerns, some issues remain:

❌ It's annoying to have to alias these (it doesn't cross assembly boundaries)

  global using EntityState = Union<MyGame.StartingState, MyGame.EndingState>;

❌ Serializing this requires use of a JsonConverterFactory, which means the user must remember to use the proper JsonSerializerOption object referencing said factory.
❌ More importantly, the Match function takes N delegates, meaning every call to Match causes N (typically 2-5) Func allocations.

Can we do better?

Records offer a relatively clean syntax for what approximates a real union type:

abstract record EntityState
{
    public record StaticState(Vector2 Position) : EntityState;
    public record MovingState(Vector2 Position, Vector2 Velocity) : EntityState;
}

This means we rely on switch expressions rather than a Match function with lambdas for each case. Unfortunately, unlike lambdas, switch expressions don't allow blocks of code. However, we can emulate them like this:

static T Invoke<T>(Func<T> func) => func();

var result = entityState switch
{
    StaticState staticState => Invoke(() =>
    {
        // Do whatever here, you got a block of code
        return 0;
    }),

    MovingState movingState => etc.,

    _ => throw new Exception()
}

If you squint, the Invoke(() => noise practically disappears. This still incurs allocations, but it's only 1 per match rather than N.
We also leverage the full power of pattern-matching here(deconstruction etc.) which isn't accessible in lambda parameters.
The thing that bugs me the most is the non-exhaustiveness and the unnecessary yet mandatory default clause e.g.

_ => throw new Exception()

I tried ExhaustiveMatching, and found that:

I still have to add a default clause to every switch
Every time I add a default clause, I have to remember to use their special exception to trigger the analyzer
When I add a case to the type I have to remember to add it to their special Closed attribute type list
- And no, this can't be automated with a source generator, as it will not run before the analyzer and there is no way to control that.

That's still a lot of potential for error. As a result, I do not feel compelled to use this analyzer.

We can make these record hierarchies serializable without forcing specific JsonSerializerOptions everywhere, by adding a JsonDerivedTypeAttribute to the base type for each case.
This can be automated with a source generator, which requires marking the records partial so the source generator can add a identically named partial record with the appropriate attributes.

To ensure the developer would not forget to add the partial keyword, I had the generator generate warnings for non-partial abstract records.

In summary, this final solution:

✔️ leverages modern language features: records, switch expressions, pattern matching
✔️ does not require usage of a specific library except for an optional source generator
✔️ does not incur excessive allocations (use of the Invoke trick above is optional)
✔️ does not suffer from value semantics complications
✔️ is serializable with minimal noise and no added maintenance burden (just a partial keyword)
✔️ approximates the proposed syntax for "Union Classes" in C#
❌ fails to achieve exhaustiveness
❌ is somewhat slow (switch on types results in several casts and branches)

This may be the best compromise until C# adds support for some kind of closed type hierarchies (e.g. Type Union Proposal).

Async gotcha: returning Task.FromResult or Task.CompletedTask

André Slupik — Fri, 01 Apr 2022 19:23:53 +0000

So you're implementing this async handler or interface method that doesn't have anything to await, and you write something like

async Task<bool> HandleAsync()
{
     DoSomethingSynchronous();
     return true;
}

But now the C# compiler emits a stern warning: "CS1998: you're using async, so you should be awaiting stuff! find something to await!"* Well, you have nothing to await, but you must still return Task. You remove async and return Task.FromResult(true) instead, as top-rated answers by high-reputation members on Stackoverflow recommend. Job done.

Task<bool> HandleAsync()
{
    DoSomethingSynchronous();
    return Task.FromResult(true);
}

Or is it?

As long as HandleAsync is always called and awaited immediately, all is fine.

var success = await HandleAsync(); // This is fine.

But this doesn't always do what you'd expect. Sometimes a try-catch fails to catch an exception.

var task0 = a.HandleAsync();
var task1 = b.HandleAsync();

try
{
     await Task.WhenAll(new[] { task0, task1 });
}
catch (Exception ex)
{
    // this handler does nothing and the exception escapes! What gives??
}

Because HandleAsync is actually synchronous, any exception propagates as soon as it's called, not when it's awaited. This is surprising to most C# programmers. A synchronous method that returns a Task is not what you expect, especially when it's called SomethingAsync. Surprising, unexpected behavior leads to bugs. Bugs lead to unhappy customers and developers alike.

So what should we do instead?

One option would be to disable warning CS1998, but it may point out cases where a method just shouldn't return a Task in the first place. Probably the best thing would be to mark the function as async and await Task.FromResult:

async Task<bool> HandleAsync()
{
    DoSomethingNotAsync();
    return await Task.FromResult(true);
}

Or if it's a plain Task, awaiting Task.CompletedTask.

async Task HandlerAsync()
{
    DoSomethingNotAsync();
    await Task.CompletedTask;
}

Is this slower? Not much - awaiting a completed task does almost nothing, and the runtime might be able to recognize this common pattern and elide all the overhead - but choosing the async-looking-but-actually-synchronous behavior for hypothetical performance reasons firmly falls in the category "evil premature optimization", in my opinion.

*Actually, it says

warning CS1998: This async method lacks ‘await’ operators and will run synchronously. Consider using the ‘await’ operator to await non-blocking API calls, or ‘await Task.Run(…)’ to do CPU-bound work on a background thread.

Seriously, stop using List in APIs

André Slupik — Tue, 29 Mar 2022 00:55:59 +0000

List<T> is to collections what StringBuilder is to strings. It's a mechanism for imperatively building a collection. List<T> is designed for things like

IReadOnlyList<Element> GetElements(IReadOnlyCollection<Element> inputElement) 
{
    var list = new List<Element>();
    foreach(var inputElem in inputElements)
    {
        if (...) 
        {
            list.Add(inputElem);
        }
    }
    return list;
}

Notice that List<T> does not appear in the function signature, our API: it is an implementation detail, a mechanism. What the API says is give me any sort of finite collection, and I'll give you back another finite, indexed collection. The caller does not need to read the implementation to understand this.

Let's see what happens if we replace the input element with List<T>.

IReadOnlyList<Element> GetElements(List<Element> inputElement)

This is now a confusing and restrictive function signature. It returns a collection, but it can also add, remove or change elements in the input collection. Does it? The caller doesn't know. He'd have to read the code, meaning that our API is no longer a clear abstraction. Furthermore the caller cannot pass in an Array, an ImmutableArray or any other collection, when these would in fact work perfectly fine for our purposes.

Don't take List<T> as an input argument unless you mean to modify that input argument. In that case, your function should probably then return void (or Task, if it's async).

void AddElements(List<T> collection); // this does make sense

Now let's look at the other case, the return type. What would this mean?

List<Element> GetElements(IReadOnlyCollection<Element> inputElement)

This is not restrictive, but it's equally confusing. The function returns a collection which may then be modified by the caller. Why? Does the function store a reference to it somewhere so it can observe the changes later? Or worse, does it modify it while it's being used? Again, this is just strange API design that prompts me to read the implementation when I shouldn't have to.

I have a hard time coming up with a good reason to return List<T>: if you have an internal mutable collection, surely it's a bad idea to share it with the outside world where it may be modified unexpectedly. Mutable state is best kept local.

Note that strictly speaking, returning IReadOnlyList<T> does not guarantee immutability either, but it does send a strong message in that direction. Strictly speaking, the correct return type would be ImmutableArray<T> or ImmutableList<T>. I'm still on the fence; libraries seem to gravitate towards the IReadOnly interfaces more than System.Collections.Immutable, for whatever reason.

Why you probably shouldn't use IEnumerable/seq

André Slupik — Thu, 03 Mar 2022 23:01:13 +0000

What's wrong with this code?

// C#:
int Sum(IEnumerable<int> items)
{
    int total = 0;
    foreach(var item in items)
    {
        total += item;
    }
    return total;
}

// F#
let sum (items: seq<int>) =
    let mutable total = 0
    for item in items do
        total <- total + item
    total

If you said, "calling this function may hang forever", you'd be right. Here's a valid value for IEnumerable<int> (seq<int> in F#) that we could pass into our Sum function:

// C#
IEnumerable<int> GenerateValues()
{
    while (true)
    {
        yield return 1;
    }
}

// F#
let generateValues () = 
    Seq.initInfinite id

Now, Sum(GenerateValues()) hangs forever.

What's wrong with this code?

// C#
interface IConfigValuesProvider
{
    IEnumerable<ConfigValue> ConfigValues { get; }
}

var values = myConfigValueProvider.ConfigValues;
if (values.Count() > 0)
{
    foreach(var v in values) { ... }
}

// F#
type IConfigValuesProvider =
    abstract ConfigValues : seq<ConfigValues>

let values = myConfigValueProvider.ConfigValues
if Seq.length values > 0 then
    for v in values do
        ...

Well, nothing, probably, but you can't really be sure. Since ConfigValues is an IEnumerable<T>, it could technically be infinite, causing Count/Seq.length to hang, although, granted, that's unlikely. What sounds more plausible is that ConfigValues is implemented as the output of calls to Where or Select, and that iterating it is computationally expensive. Note that we're potentially causing it to be iterated twice here (calling Count and then doing a foreach), which would be bad if it was computationally expensive. Of course, the caller expects this to behave like an Array-like collection, but as a matter of fact, IEnumerable<T> makes no such promises. A potential solution here would be calling ConfigValue.ToArray() and using the result of that, but that's going to create a pointless copy if ConfigValues is actually just a collection. We can't know, so either we make unsafe assumptions, or we code defensively and waste resources.

IEnumerable<T>/seq<T> does not represent a collection of items, so it should not be used to represent collections of items.

So what should we use? Is there another interface that all collections implement and provide a guarantee that it's actually a collection? Yes, there is, and it's called IReadOnlyCollection<T>, introduced in .NET 4.5, August 15th, 2012. If you want to be more specific and get true array-like behavior (with indexing support), IReadOnlyList<T> has got your back. I'm leaning towards IReadOnlyList<T> for everything that has an index (arrays, List<T>, ImmutableArray<T>, etc.) and IReadOnlyCollection<T> for everything else (LinkedList<T>, Queue<T>, Stack<T>, etc.) There might be cases where concrete immutable collections like ImmutableArray<T> are better though, especially as a return type. Returning a concrete type seems to provide greater value. I haven't found great, clear guidance on e.g. IReadOnlyList<T> vs ImmutableArray<T>; if you have an opinion on that, please share!

Finally, if IEnumerable<T> does not represent collections, and we have a perfect replacement for it, what use does it have?

IEnumerable<T> is anything that supports enumeration: collections, infinite sequences, computations of successive values. It is the perfect type to define mappings over arbitrary, non-finite sequences of data. Think of LINQ operators Where, Select, which also return IEnumerable<T>: those make perfect sense and could not use a better type. Do not think of scalar-returning functions like Enumerable.Sum or Enumerable.Count which IMO shouldn't exist, as they don't make sense (and won't work) over anything but finite collections.

I suspect that the late addition of IReadOnlyCollection<T> and friends to .NET is largely to blame for the widespread use of IEnumerable<T> as a read-only view of a collection. After all, IEnumerable<T> arrived in .NET 2, early 2006, and System.Linq arrived in .NET 3.5, late 2007. F#'s Seq module, probably designed around the same time, is full of the same issues as System.Linq: Seq.sum, Seq.length, Seq.append, Seq.toList, Seq.toArray, etc. are all very practical, but definitely not sound.

F# features C# will never get

André Slupik — Wed, 02 Mar 2022 04:30:07 +0000

C# has made huge strides in enabling programming with values and data transformation, as opposed to mutable entities. While C# generally embraces mutability, its records are immutable. Their concise syntax eliminate any arguments for primitive obsession. Switch expressions and pattern matching allow more logic to be expressed as a chain of expressions rather than imperative logic. Like early spring flowers poking out of the snow, there's even some traction to break free from classes, with a classless Program.cs or ASP.NET Minimal APIs. The C# compiler team seems determined to eventually add primary constructors and discriminated unions. With C# destined to get full algebraic data type support, one is bound to ask: will F# remain relevant?

While C# is undoubtedly more and more capable, its roots in the C family of languages (C, C++, Java, JavaScript) will always make the experience of writing code in it somewhat akward in my opinion. F# remains and will remain vastly more concise, flexible and, to be perfectly objective, fun.
Here are some F# features C# will probably never have:

1) Curried functions

Curried functions enable partial application, which enables dependency injection without objects. While C# takes some steps back from object orientation, it has to remain object-based. In contrast, F# offers the flexibility of programming with functions or objects: both are just as powerful. While it's possible to write a curried function in C#, the lack of language support and type inference for it makes it impractical. With no traction for it in the community as far as I'm aware, we'll probably never see this feature in C#.

// Wait what?
Func<T, Func<U, Func<V, TResult>>> CurriedFunction(...

2) Global type inference

F# features full Hindley-Milner type inference, which enables writing in a functional style without the inconvenience of spelling out painful type signatures. It also largely contributes to F# programs being much more concise than the C# equivalent. This is heavily dependent on the expression-based nature of F#. Expressions have types; statements do not. While C# could make small improvements on its type inference, there's very little chance it could ever infer argument types or even return types.

3) Automatic generalization

As F# performs type inference, it tries to come up with generic function signatures as much as possible. As C# does not and cannot ever infer function signatures, it cannot do this either.

4) Immutability consistently, by default, everywhere

F# defaults to immutability everywhere: in its let bindings, its function arguments, constructor arguments, class fields, but also its native collection types: List, Seq, Set, Map are immutable; Array is not (it's just the .NET Array), but the Array module leans heavily towards copy-and-update operations.
C# seems decidedly undecided, with immutable records but mutable tuples, and of course mutable everything pre-records. Immutable collections exist (in System.Collections.Immutable), but they lack language support (ImmutableArray<T>.Empty vs new T[0]) and amazingly do not provide value equality.

5) Pipe-forward operator

So much C# code is just

var thing = GetThing();
var propertyOfThing = thing.GetProperty() ?? thatOtherThing;
var transformedThing = Transform(propertyOfThing);
// etc.

While adding named variables can help with clarity, let's just face it, these were added here because a long chain of transforms looks bad as a single expression, e.g. Transform(GetThing().GetProperty() ?? ... is not super readable. Even spread out over multiple lines, it's still a bit all over the place, with logic sometimes flowing left to right (thing.GetProperty() ?? thatOtherThing) and sometimes right to left (Transform(propertyOfThing)). The F# pipe operator fixes all of that:

it alleviates the need for trivial variable names
it lets the logic flow left to right, top to bottom, the way we naturally read text
and it promotes free functions

let thing = GetThing()
thing.GetProperty()
|> Option.defaultValue thatOtherThing
|> Transform
|> etc.

The closest thing C# offers is fluent APIs.

Now this one might theoretically happen for C#; it has actually been discussed for a long a time. JavaScript, a language much closer to C# than F#, is very seriously considering it (see tc39). However, I would not count on this happening for a long while.

Comparing IAsyncEnumerable and IObservable for event streams

André Slupik — Wed, 23 Feb 2022 16:15:22 +0000

I spent a day experimenting with both approaches for representing and manipulating streams of events and here are some preliminary thoughts.

Similarities

Both can represent a stream of events or messages.

Both define LINQ-style operators like Select, Where and Aggregate, making it easy to manipulate the streams.

Both allow merging two streams into one. Note that at the time of writing, the appropriate method for this with IAsyncEnumerable is AsyncEnumerableEx.Merge from System.Interactive.Async, not the extension method of the same name, which behaves differently, concatenating the input streams rather than interweaving their results as they arrive.

Differences

`IAsyncEnumerable`

It's a pull model: items are created on request as the consumer iterates the stream, just like with IEnumerable. This implies that there needs to be some buffering between where your events are produced (e.g. from the real world, from a message broker, etc.) and when they are consumed. System.Threading.Channels.Channel is designed to fulfill this need.

Has strong traction in the dotnet ecosystem, with language integration in C#8 both for consuming (await foreach) and producing (transforming async IAsyncEnumerable functions into async iterator generators). System.Threading.Channels is a currently recommended approach (source) for producer/consumer scenarios.

Integrates well with async/await.

Encourages an imperative style: the language integration consists of a foreach loop, which means mutable state. That said, it's easy to define additional extension methods to allow writing in a more functional style. Here's an equivalent of F#'s choose for IAsyncEnumerable:

public static async IAsyncEnumerable<TResult> Choose<TSource, TResult>(
    this IAsyncEnumerable<TSource> source,
    Func<TSource, TResult?> selector)
{
    await foreach (var item in source)
    {
        if (selector(item) is { } result)
        {
            yield return result;
        }
    }
}

IEnumerable and Task are two concepts most C# developers interact with on a daily basis, so the combination of the two should be fairly intuitive.

Support for F# is planned, in the form of taskSeq.

`IObservable`

It's a push model, similar to C# events: you subscribe a synchronous handler and it gets called whenever an event happens. If you have asynchronous work to do in response to the event, you could convert its output to another IObservable; this approach is described here. The IObservable<->Task interop story seems solid, but the back-and-forth seems like an unavoidable point of friction. Task is a pull model; IObservable is a push model. Task permeates more and more of the dotnet ecosystem every year, it seems, for better or worse.

Documentation on how to create Observables and Observers is surprisingly hard to find. ReactiveX, the open-source project, has a high-level, language-agnostic documentation, which is not enough to fully understand how to use Rx.Net specifically.

The MSDN documentation exists, but is above 10 years old and not currently maintained.

Googling for examples yields mostly results for RxJS or RxJava. Blog posts or SO questions tend to date 5-10 years, which doesn't necessarily make them wrong today, but means they're not taking into account the current state of the dotnet ecosystem.

Admittedly, the story isn't that great for IAsyncEnumerable documentation either: googling AsyncEnumerable.ToArrayAsync sends me to Entity Framework documentation and if the real doc for System.Linq.AsyncEnumerable exists anywhere, let me know.

The thing is, I don't need to form a new conceptual model to understand what ToArrayAsync is going to do, or what await foreach will do. To use IObservable, I need to understand new terminology such as hot vs cold observables, what Publish does, what Subscribe does, what a Subject is and when should I use it; how to avoid deadlocks which are reportedly easy to run into; how and when to properly call OnNext/OnError/OnCompleted - should I use try-catch-finally on all my logic to make sure I call these reliably? What really happens when exceptions are thrown, are they just propagated or do they stop the stream? I need guidance and best practices if I'm to introduce a new library to a team project, especially one with a high learning curve and deadly gotchas, and the fact that I, or colleagues on my team, can't refer to an official up-to-date doc means this is probably a no-go.

In conclusion

Well, I meant to write an objective pro/cons list, but this turned out into a long rant against IObservable, didn't it? The fact is, the push model appeals to me and seems very powerful. Rx makes it easy to define and manipulate streams of events, and if I could find the time to learn it properly, I feel like it could help me come up with even more elegant solutions than what Channels and async streams allow. The fundamental issue is that the Task-based, pull model seems to have slowly taken over everything in dotnet in the past decade. With IAsyncEnumerable having language integration in C# and little in the way of new concepts, it's very hard to argue for a competing model, especially without proper guidance and documentation for that model.

That said, this was the result of a single day of investigation, so keep in mind this is a pretty superficial overview. I look forward to deepening my understanding of this topic in the future.

Further reading:
A good discussion of async pull vs IObservable: https://fsprojects.github.io/FSharp.Control.AsyncSeq/AsyncSeq.html

Don't make these 5 F# mistakes

André Slupik — Tue, 14 Dec 2021 21:26:43 +0000

I'm lucky enough to be working full-time at a company that uses F#, so here are some observations I compiled from doing code reviews on real-world codebases.

Correctness:

1) Prefer `string` to `.ToString()`

let i:int option = None
i.ToString() // throws System.NullReferenceException

// Safer ways to obtain a string representation:
string i // ""
"${i}" // ""
sprintf "%O" i // "<null>"
sprintf "%A" i // "None"

2) Don't use `failwith` or `failwithf`

It throws System.Exception: this violates .NET Exception guidelines. From experience, it's can be very annoying to debug a project where you need to break on System.Exception, as any random code can throw it.
Defining your own exception type in F# is a one-liner, so do create your own exception types.

// DON'T:
failwith errorMessage

// DO
exception OrderValidationException of string
raise (OrderValidationException errorMessage)

Style:

Note that the code in the following examples is perfectly fine as-is.
These are just opportunities to keep in mind to make the code easier to read.

3) Don't use `fst` and `snd`...

... at least when a simple destructuring pattern would suffice. These are terribly named functions. You can't get anything but the 1st or 2nd element that way. It makes it hard to understand what was extracted unless the result is immediately bound to an identifier.

setupUnitTestMocks ()
|> fst  // what's this??
|> testWith

Prefer destructuring, with the added bonus that this will look familiar to C# and JS programmers:

// Ah it's a mock of a database
let databaseMock, _ =
    setupUnitTestMocks ()

testWith databaseMock

4) Don't abuse lambdas

F# makes it so easy and convenient to use pipe-to-lambda for everything that sometimes we forget we can use plain let bindings, match statements, for loops etc. Lambdas make code flow trickier to understand (what's the argument? what's being returned?).

let orderInfo =
    Order.create (Guid.NewGuid().ToString())
    |> function
        | Result.Ok validatedOrder -> validatedOrder
        | _ -> raise (OrderCreationException "This should never happen")
    |> fun order ->
        { Order = order
          Description = String.Empty }

We can reduce indentation and make this code easier to follow with a let binding, and replacing the function with a match statement.

let orderInfo =
    let order =
        match Order.create (Guid.NewGuid().ToString()) with
        | Result.Ok validatedOrder -> validatedOrder
        | _ -> raise (OrderCreationException "This should never happen")

    { Order = order
      Description = String.Empty }

5) Don't systematically add parentheses around function arguments

This is a hard habit to get rid of coming from C-style languages, but function invocation is indicated by spacing, not parentheses.

Systematic use of redundant parentheses make F# code slightly heavier than it needs to be.
I want to stress that this is purely stylistic, but I suspect most F# programmers do this out of habit, not conscious thought.

// OK:
events.OrderReceived.Trigger(incomingOrder)

// Better:
events.OrderReceived.Trigger incomingOrder

This includes constructors too, which are just functions

let orderReceivedCompletion =
    TaskCompletionSource<_> TaskCreationOptions.RunContinuationsAsynchronously

Special thanks to Don Syme for reading this article and suggesting some improvements.

Did C#9 kill optional constructor parameters?

André Slupik — Wed, 25 Aug 2021 17:48:47 +0000

Init-only setters, introduced in C# 9, allow for a concise alternative to named optional constructor parameters. Let's illustrate and then discuss the pros and cons.

As you can see in the example below, the amount of repetition involved in getting a private readonly field initialized with an optional constructor parameter (that's a mouthful, but it's a common thing to do) has traditionally been insane. I have to write the name of each field 4 times and specify their type twice to get a readonly optional field.

class C1
{
    readonly Action onOpen;
    readonly Action onClose;
    readonly Action onBegin;

    public C1(
        Action onOpen = null, 
        Action onClose = null, 
        Action onBegin = null)
    {
        this.onOpen = onOpen;
        this.onClose = onClose;
        this.onBegin = onBegin;
    }

    // ...
}

// usage:
var c1 = new C1(
    onClose: () => Console.WriteLine("OnClose called")
);

As it turns out, properties marked as { private get; init; } can fill the same role with no code repetition, cutting down clutter by two thirds!

class C2
{
    public Action OnOpen { private get; init; }
    public Action OnClose { private get; init; }
    public Action OnBegin { private get; init; }

    // ...
}

// usage:
var c2 = new C2() 
{ 
    OnClose = () => Console.WriteLine("OnClose called") 
};

As the getter is private, the property can only be accessed in the object initializer, making it equivalent, for our purposes, to a named optional constructor parameter.

Since this class has no required constructor parameters, it can do away with a constructor entirely. This pattern could even work with required parameters in the future, if required init-only properties make it into a future C# version, C# 10 or C# 11 perhaps? The syntax would hypothetically look like this:

class C2
{
    public required Action OnOpen { private get; init; }
    public required Action OnClose { private get; init; }
    public Action OnBegin { private get; init; }

    // ...
}

// usage:
var c2 = new C2() 
{ 
    OnClose = () => Console.WriteLine("OnClose called"),
    // compilation error: OnOpen must be provided
};

4 or 5 keywords per property is a bit intense to be sure, but I'd take it over the sheer massive boilerplate it replaces.

I'm not sure at this point what the drawbacks would be. A couple I can see so far:

The property appears in code completion since it's public. It won't be possible to use it outside the object initializer, but this might be a bit confusing. This is more of a glitch of code completion than anything else.

// code completion will suggest OnClose at this point
Console.WriteLine(c2. 

// but it's inaccessible, so you just get a compiler error
Console.WriteLine(c2.OnClose) 

// code completion could be smarter, but that's what we have today

It creates a slight discoverability issue for the consumer, as all constructor parameters appear in code completion, but init-only properties only appear when opening an object initializer, which a user might just forget to do, or wonder how the object is to be used.

var c1 = new C1( // see list of constructor arguments appear
var c2 = new C2( // code completion shows nothing at this point
var c2 = new C2() { // only now you get your property names

Both of these issues mainly stem from unfamiliarity with the pattern, so I don't think they're necessarily roadblocks.

What do you all think?

F#'s Stack Overflow community is amazing

André Slupik — Wed, 09 Dec 2020 14:15:58 +0000

I recently asked a question about F# syntax on Stack Overflow. It seemed like a weird edge case with indentation, and I did not expect many people to have encountered this; if they did, they were unlikely to know the answer as it would be quite technical. Still, I wanted to do due diligence before opening an issue on the F# compiler repo.

// This is just an alias of |>
let inline (|>!) (a: 'T) (f: 'T -> 'U) = f a  

Some 5
|> function
| Some b -> 
    b
| None ->
    0
|>! printfn "%d" // FS0001: The type 'int' does not match the type 'unit'

// if you replace |>! with |> it compiles, even though
// it's literally the same operator
// seriously, who's going to know the answer to this
// or so I thought

Lo and behold, it had already been asked, and already had a great, detailed answer by user Fyodor Soikin. He pointed me to it literally within minutes of my post. I was amazed.

For the curious, a short version of it would be this. While a human reads the above as:

Some 5
|> (function
    | Some b -> b
    | None -> 0)
|>! printfn "%d"

Because my operator has 3 characters instead of 2, this pushes the printfn one space, right under the 0 above, and F# interprets it as:

Some 5
|> function
| Some b -> 
    b // this is an int
| None ->
    0 |>! printfn "%d" // this is unit, so the types mismatch

But that's not really the point of this blog post; see the linked question for the juicy technical details.

I've had this experience several times now over my many years of using F#, where I'll ask something simple and then get an answer from someone like e.g. Tomas Petricek, just to name one, with great thought and care, rigorous detail and technical clarity. The level of passion and knowledge demonstrated by many F# community members never ceases to impress me. Even compared to other great SO communities, F#'s feels more friendly, passionate and technically proficient.

Coming from more mainstream languages, one might think moving to a smaller community would make it harder to find support. I think the F# community demonstrates that's not about quantity but quality.

Fixing a bug in the F# compiler

André Slupik — Sun, 29 Nov 2020 16:37:12 +0000

A couple weeks ago, a PR of mine was merged into the F# compiler repo, fixing an issue that bothered me with unused open statement detection. Even just a few years ago, this would have seemed like a daunting task to me, so this felt like a real achievement.

A great motivator for me was to watch this relaxed, slow-moving presentation from Don Syme (the man himself), fixing a bug in the compiler live. It is filled with useful nuggets of information about the structure of the codebase and coding conventions, and that definitely helped me get around and understand what I was looking at.

I then read the available documentation, which is high quality: the README, the DEVGUIDE, and the Compiler Guide. I really appreciate that all this documentation is right there in the repo, it makes it easy to access, consume and update.

Having worked with Github daily for about a year, I had become familiar with the PR process. Nonetheless, one mistake I made was to clone the actual dotnet/fsharp repo instead of forking it and then cloning my fork; once I had the fix commited, I was unable to push it as, of course, I don't have the rights on dotnet/fsharp. If that happens to you, it's easy to retarget your local repo to your fork with

git remote set-url origin https://github.com/yourusername/yourfork.git

Now you'll be able to git push your changes as they'll go to your fork.

I made the mistake of trying to debug the F# tools on the currently released Visual Studio. Currently, this requires Visual Studio Preview, which can be installed side-by-side.

I also got a mysterious error trying to run the tests but you can always run the tests directly on the compiled dll with dotnet test <your test dll>. I also added --verbosity detailed to get the result of each test printed to the console.

Overall, I'm surprised the process was so straightforward for what is a large codebase with a long history. The F# tools definitely need some love, so I hope this helps someone out there trying to improve them.

DEV Community: André Slupik

ReScript is not there yet

Discriminated unions in 2024

What about OneOf?

Can we do better?

Can we do better?

Async gotcha: returning Task.FromResult or Task.CompletedTask

Seriously, stop using List in APIs

Why you probably shouldn't use IEnumerable/seq

F# features C# will never get

1) Curried functions

2) Global type inference

3) Automatic generalization

4) Immutability consistently, by default, everywhere

5) Pipe-forward operator

Comparing IAsyncEnumerable and IObservable for event streams

Similarities

Differences

IAsyncEnumerable

IObservable

In conclusion

Don't make these 5 F# mistakes

Correctness:

1) Prefer string to .ToString()

2) Don't use failwith or failwithf

Style:

3) Don't use fst and snd...

4) Don't abuse lambdas

5) Don't systematically add parentheses around function arguments

Did C#9 kill optional constructor parameters?

F#'s Stack Overflow community is amazing

Fixing a bug in the F# compiler

`IAsyncEnumerable`

`IObservable`

1) Prefer `string` to `.ToString()`

2) Don't use `failwith` or `failwithf`

3) Don't use `fst` and `snd`...