Lately I’ve been playing a bit with F#, as I was curious how the closest OCaml relative compares to OCaml, and I liked some small bits and pieces there. E.g.:
being able to use // for comments in addition to (* *)
The range syntax (e.g. [1..2..20])
The shorthand lambda syntax for accessing fields in records (e.g. _.name instead of something like (fun r -> r.name)
Function composition with >> (obviously everyone can do this for themselves in OCaml, so not really a big deal)
There are many other interesting differences in F# (e.g. I like that scopes are introduced with indentation and the syntax is slightly more compact here and there), but not all of those can be brought to OCaml for various reasons.
I’m curious how many of you keep an eye on what’s happening with F# and whether there are F# features that you’d like to see make their way into OCaml one day.
Perhaps a controversial take, but I’d like to see significant whitespace in OCaml so we don’t have this “problem” with nested match expressions.
(I realize there have been past and present OCaml frontends that do the same thing with curly braces, but I’ll take whitespace over curly braces any day of the week in a language with ISWIM-based syntax)
I’m guessing that’s doable, but unlikely to happen as from what I’ve gathered for a very long time F# supported both its current syntax (called “light”) and the OCaml one (via a directive to turn off the “light” syntax).
Oh, yes. I have no real hope that significant whitespace will ever be in OCaml. It’s just something I think F# (and Haskell, for that matter) does better than OCaml.
Seems there’s not much interest in a discussion on the topic - I guess very few people keep track of what’s happening in both OCaml and F#. What prompted my interest in it originally was that to my knowledge F# made the pipeline operator |> popular, and it was eventually adopted in OCaml as well. Perhaps there were other cases when something like this has happened in the past? I also know that async/await (very prominent in JavaScript) originated there as well. And it’s well-known that F# was something like an incubator for C# improvements.
In general I am curious how similar languages can cross-pollinate ideas - the topic is not which language (F# or OCaml) does X, Y or Z better, it’s how they can help each other be better overall. I’m also curious if people from the OCaml Core team collaborate with the F# Core team.
I always though that async is a return and await is just a running of async monad transformer. It should be originated in Haskell in mid 90s (Can find easily a paper though)
My impression is that async/await in F# was indeed inspired by do notation in Haskell, but got into C# and then other mainstream languages via F#. F# didn’t invent monadic control flow, but I think they should be given credit for finding an application of it that was so obviously useful that mainstream languages couldn’t ignore it.
Just a shootout to @NatKarmios whose first post it seems was considered a spam by the system. He suggested @v-gb’s software. I tried to unspam your message but didn’t find a way (or I don’t have the rights).
The 2011 paper about F#'s asynchronous programming model mentions taking inspiration into monadic delimited continuation and as a few references (notably, lwt :–).
And yes async/await and other ? language keywords are just about hard-coding a selection of monads in your language (except when it’s not).
I think that making whitespace significant would be a very intrusive syntax change for this purpose alone. It would be simpler to require that match and function have an explicit end. (But of course, even that would be likely too intrusive at this point in OCaml history.)
There have historically been different OCaml frontends that can do this kind of thing on an opt-in basis, though I don’t think there are any that specifically do whitespace (or end)
Imho the most realistic ‘features’ that OCaml can ‘adopt’ from F# are not really features, and not specifically F# things either, but more so things that would be good to have in the standard library. Eg, we really need a good async I/O implementation out of the box so we can finally stop splitting the community into multiple async I/O library ecosystems which has been holding back progress for a long time.
Unit of Measure: Floating point and signed integer values in F# can have associated units of measure, which are typically used to indicate length, volume, mass, and so on. This seems pretty nice for numeric code. How it holds up using it in a project I’m not sure?
Type Providers as a well supported and easy to use feature. Being able to generate code from an OpenAPI specification is heaps more work in OCaml than it should be.
Computation Expressions look interesting, though I’d use something like do syntax from Haskell rather than the F# version.
Finally some combination of Statically Resolved Type Parameters and Modular Implicits would help with writing generic code across a particular interface ala TypeClasses in Haskell.
I no longer use F# but I checkout their announcements when a new version is released.
Computation expressions.
While they’re mostly used for async {} (task {}) related stuff, they can be quite flexible to implement general DSLs as wells. E.g. there is an official implementation for query expressions, FsHTTP to build up HTTP requests, this slide deck DSL which uses a cross platform GUI toolkit or even an exotic (toy) example on how to generate inline assembly.
A less intrusive (but also admittedly less elegant) solution is to deprecate bare function and match and recommend instead begin function … end and begin match … end. It’s backwards compatible.