Hacker News Reader

Comment by aardvark291 | Hacker News Reader

How does F# compare to OCaml or Haskell?

F# started as Ocaml for .Net and then added all sorts of pragmatic language constructs. I'm not an expert - F# AFAIK misses some of the higher level type theoretic stuff, but you can write 'basic' Ocaml that would be isomorphic with F#.

The key high level features that F# inherits from Ocaml is a succint syntax due to type inference and 'if it compiles it's bug free' development.

Does "if it compiles it's bug free" actually work in practice? I've heard a lot of advocates for Haskell and Rust use similar lines to this, but it seems to me like it can only be true for a limited subset of all bugs. Elm's "no runtime errors in production" claim has a more reasonable-sounding scope.

Sure, it's limited to a subset of all bugs but with a proper typesystem the category of bugs you can remove from code by just encoding the semantics and algebra into the types is quite large.

So if you know how to formulate the problem so it leans heavily on the type system, you can implement something like a binary tree container, and presume it is correct when it compiles.

Following the same parameters bestows rest of the codebase with this robustness.

See for example the ACM article "Ocaml for the masses" by Yaron Minsky of Jane Street for very lucid practical examples https://queue.acm.org/detail.cfm?id=2038036

... to be fair, it takes a bit getting used to a compiler that is as strict, but, when you learn how you need to implement various things, it increases your velocity since you can type stuff and not bother with too much intermediary testing because you can trust you've pretty much typed as you meant.

"It doesn't eliminate bugs, but the bugs that remain are better bugs".

Better bugs in this context is bugs at a higher level, eg. application logic issues.

F# is missing OCaml modules and functors, which are the biggest reason to prefer OCaml versus other similar languages. OCaml also has structural typing via row polymorphism. And GADTs.

It's easy to dismiss this as "type theoretic stuff", however these features we are talking about are very natural to use and when dealing with static typing and FP you bump into them quite a lot. And given that OCaml has some of the best type inference in the business, this happens without you even knowing about it.

F# is also missing a means for doing ad-hoc polymorphism like in Haskell. So no type class capabilities, no higher kinded types either. This greatly diminishes what you can express in it and the gymnastics you have to pull off to work around it are not fun.

Here's for example what you need to do in absence of GADTs: http://fssnip.net/mq (n.b. this pattern is called "tagless final", resembling "visitor" from OOP land).

I love this sample because if it looks complex, well it's in fact more complex than it seems, as the type system is actually not fine with this usage either, so you end up with forced type castings anyway.

---

F# is a fine language, all things considering and not having certain features might be considered an advantage in certain circles.

However do learn OCaml and Haskell, because they have plenty to offer and you'll learn useful abstractions that in F# are not very accessible.

F# has operator overloading, which is missing from ocaml?

I'm not sure if I'd phrase it in terms of something missing from OCAML (or F# for that matter).

There's a substantial diff between OCAML and F# at this point, once you get past "core" programming with functions in both languages. Some of the more prominent things F# has that

* Computation Expressions

* Perf abstractions and compiler analysis for them, namely Span<'T>

* Type Providers

* The .NET generics system

* Anonymous Records

* Slices and ranges for slicing or generating list-like data

And as the parent user said, there's plenty OCAML offers that is missing from F#. I think it's a good idea to consider them quite differently, despite having the same functional core.

It's interesting to compare some of those things, though.

* OCaml has now landed monadic and applicative binding syntax ( http://jobjo.github.io/2019/04/24/ocaml-has-some-new-shiny-s... ), which I think makes it a superset of F# computation expressions.

* Regarding Span<'T> (or my preference 'T Span :-), I believe F# and OCaml have developed different optimizations and constraints. For example, in OCaml allocation is really cheap. But there are still well-known techniques for minimizing it.

* OCaml also has the PPX system, which allows to programmatically transform a program's syntax tree into a new tree. I believe this allows somewhere around the same power as type providers and quasiquotations, combined.

* Anonymous records are cool, OCaml objects are pretty similar in that they are structurally typed. Also interestingly neither of them supports pattern matching–if I recall the F# limitation correctly.

* Slices and ranges are cool, in practice there are pretty powerful and well-known OCaml libraries that provide those, e.g. https://ocaml.janestreet.com/ocaml-core/latest/doc/base/Base...

That is by design. OCaml philosophy has been to be explicit about code. It's very Go-ish in that sense. So for example integer and float operators are different:

    let int3 = int1 + int2
    let float3 = float1 +. float2

However OCaml does allow operator redefinition and shadowing, so you can redefine and use any operators you want just by opening their specific modules (local opens, i.e. module opens that last for the scope of a single expression, are preferred):

    let int3 = Int.Ops.(int1 + int2)
    let float 3 = Float.Ops.(float1 + float2)

Note: the above modules Int.Ops and Float.Ops are for illustration purposes only, they don't exist in the standard library. You could write them pretty easily, though.

My Ocaml is rusty, but I am pretty sure you can do Int32.(3 + 2) or similar. This may be the core library though..

This isn’t really true.

You can do: let ( + ) a b = ...

Just fine

That's a custom operator definition. Operator overloading is when the same operator can be used on different types (for example, if `+` worked on both floats and ints, instead of explicitly having to reach for the correct `+` like you do in OCaml).

Which can be done, since OCaml has objects

    let (+) a b = a#add b

Yeah, I guess you can get a limited sort of operator overloading by building it out of row polymorphism. That doesn't solve the most common use-case of operator overloading, though, which is allowing the same operators to work on floats and ints, because it only works on objects.

At $WORK we use initial algebras in F# instead of tagless final. (They're isomorphic ideas.) It's possible to hack up a GADT using the initial algebra pattern, if you have existential types (which you can get via skolemisation) and type-equality types (which you can pretend exist as a pair 'a -> 'b and 'b -> 'a).

What is a GADT?

"Generalised algebraic data type". Pattern-matching on a GADT not only gives you information about the term that was in the datatype, but also about a type that was in the datatype.

For an ADT that doesn't need the power of GADTs: pattern-matching on a List<'a> gives you either an Empty or a Cons(x, xs), where you know up front before you do the pattern-match that x and xs are of type 'a and List<'a>.

For a GADT that is not an ADT: pattern-matching on an Expression might give you "Const(a) where a is an int", or "Equal(a, b) where a, b are bools", etc. Without doing the pattern-match, you can't necessarily tell what types you've ended up with.

Reply on news.ycombinator.com