Login

r/fsharp

Am I on the right track?
▲ 23 r/fsharp

Am I on the right track?

I created a simple debit and credit console app using the Result and Option types, along with computation expressions. So, gang... am I on the right track here? I didn't use AI at all — just based on my understanding of the concepts. What do you all think?

Next step, I'm going to try working with a database, maybe with Dapper as ORM? I don't know how it will go, but I'm sure it will be fun.

What improvements do you suggest in the above code?

u/existentialnonormie — 1 day ago
▲ 64 r/fsharp+3 crossposts

I have spent some time recently reimplementing Mojang's DataFixerUpper library (which handles serialization and data transformation through the lifetime of a project) in C# with a few of my own takes on it. It uses literally zero reflection and rivals the built-in System.Text.Json library in allocations, sometimes even beating it (although latency is a bit of a problem right now because I'm not batching operations together), as evidenced by the benchmarks:

| Method                     | Mean     | Error    | StdDev    | Median   | Gen0   | Allocated |
|----------------------------|---------:|---------:|----------:|---------:|-------:|----------:|
| STJ_Serialize              | 237.9 ns | 24.37 ns |  71.86 ns | 194.4 ns | 0.0343 |      72 B |
| STJ_Serialize_IntArray     | 186.2 ns | 20.36 ns |  60.02 ns | 142.0 ns | 0.0191 |      40 B |
| STJ_Deserialize            | 321.7 ns |  5.65 ns |  10.19 ns | 318.4 ns | 0.0801 |     168 B |
| STJ_Deserialize_IntArray   | 198.2 ns |  2.63 ns |   2.46 ns | 197.5 ns | 0.0534 |     112 B |
| Codec_Serialize            | 546.0 ns | 59.11 ns | 174.29 ns | 418.2 ns | 0.0534 |     112 B |
| Codec_Serialize_IntArray   | 393.4 ns |  2.92 ns |   2.28 ns | 392.7 ns | 0.0610 |     128 B |
| Codec_Deserialize          | 524.7 ns |  5.14 ns |   4.29 ns | 524.2 ns | 0.0305 |      64 B |
| Codec_Deserialize_IntArray | 475.7 ns |  4.07 ns |   3.40 ns | 475.0 ns | 0.0343 |      72 B |

The library is designed in such a way that you can create tiny codecs for structs/classes and compose them together to serialize even complex/nested DTOs seamlessly. You can also define "timelines" for your objects and pass their serialized versions through transformation pipelines to add/remove/rename keys.

The library also happens to be format-agnostic by design, so the exact same APIs would work with a backend for cbor, custom binary, yaml, burping into the mic vocoded into gangsta's paradise or any other format you might think of.

u/AnnoyingMemer — 5 days ago
▲ 8 r/fsharp

C# Union Types

Hi guys,

What do you think of C# Union Types coming in .Net11?
Interop with C# will be difficult if .net libraries written in C# exposes those types in their API.

Maybe .net should have considered building a unified approach based of existing F# DU from the start instead of doing this then making F# eventually catch the train in a future release.

I have never done video game development but I clearly remember when Godot released a new version and you could not use anymore full F# because of their using of a specific C# feature.

reddit.com
u/EmergencyNice1989 — 6 days ago
▲ 9 r/fsharp

Is it important to know how memory works to fully understand f#?

So I work on a e-commerce marketplace and after realizing doing complex rules and validation in typescript is hell on earth I looked for another solution and I stumbled upon f# which was perfect. We use it mainly as a domain server where a domain in the system is getting too complexed.

I’m the only person that can work on this and I want to teach a couple of my coworkers f# but they have no idea how memory works not even stacks and heaps, and with a language like f# I feel like you can’t really get away with not knowing how it works like typescript

So I was wondering do you think f# is one of those languages you can learn without fully understanding how memory works

reddit.com
u/Montrell1223 — 10 days ago
▲ 18 r/fsharp

Decoding the Indus Valley script with F# — 16 Alloy assertions, SqlHydra-typed read path, dotnet fsi reproducibility

I just published a paper using F# end-to-end to test a hypothesis about the Indus Valley script (the writing system from the Harappan civilization, ~2600–1900 BCE, still undeciphered).

GitHub: https://github.com/chanakyan/ledger-of-meluhha

License: BSD-2-Clause (human use), AI use prohibited

The hypothesis: the script is not a phonetic language. It's a five-field cargo-tag system encoding merchant, commodity, weight tier, quantity, and route — essentially Bronze Age barcodes for goods moving Lothal → Dilmun → Ur.

The F# stack:

Verification before implementation. Sixteen Alloy 6 assertions written first against the schema. All UNSAT at scope 6. SQL was written only after the schema was machine-verified consistent. The Alloy → F# bridge lives in lib/alloy-fsx/, which also includes an AlsParser.fs (recursive descent + Pratt expression parser) that parses 37/116 of the AlloyTools model zoo.

Read path vs write path separation. Raw SQL is permitted only in *_to_sqlite.fsx scripts (the ingest write path). The read path uses SqlHydra-generated typed queries in hydra/IndusCorpusQueries.fs. A pre-commit hook enforces this — raw SQL in non-ingest files fails commit. This means once data is in SQLite, every query is type-checked at compile time, no ad-hoc strings.

Discriminated unions as S-expressions. The paper, the website, the SQL ingest, and the SMT proofs are all generated from a shared F# DU tree. Knuth's WEB insight generalized: code and documentation are one artifact viewed N ways. The viewing function is a fold over the DU. F# DUs already are S-expressions; the type system is the structure; pattern matching is the evaluator. No separate S-expression parser needed.

Reproducibility on dotnet fsi.

git clone https://github.com/chanakyan/ledger-of-meluhha

cd ledger-of-meluhha

dotnet fsi indus_decoder.fsx

And get the same decode results as the paper. No proprietary toolchain. The 10-minute verification protocol in the paper's "For Journalists" section is meant for non-programmers — but for F# folks it's faster than 10 minutes.

The decode itself. Two Mohenjo-daro seals (M-52A and M-148A) end-to-end through the codebook. Mass decode across 179 inscriptions: 65% commodity assignment, 21% route assignment. Sign 342 (jar motif) dominates the corpus at ~10% — anomalous for a phoneme, expected for a commodity class.

Why F# specifically. I tried Python first. The strings-everywhere problem killed correctness — silent typos in sign IDs produced plausible-looking garbage decodes. F# DUs made invalid states unrepresentable. The compiler caught dozens of bugs Python had let through.

The paper is in ledger_of_meluhha.tex (3,657 lines, ~150 KB). The corpus databases are in indus_corpus.db, indus_codebook.db, indus_lssc.db. The decoders are seven .fsx files at the repo root.

Happy to answer questions about the typed-records pattern, the Alloy-to-F# generation, SqlHydra integration, or the F# DU → multi-target weave architecture. The cross-domain stuff (the Bronze Age trade history) is in the paper for those interested.

reddit.com
u/chanakya_ — 10 days ago