Standard ML in 2020

I was under the impression that ocaml’s optimization was pretty good. Granted multicore is not here yet.

In Haskell's defense, they meant to do that.

SML records are structurally typed and may be anonymous which makes a lot of things easier to write. I've heard Ocaml has been attempting to tack that on, but that leads to the next point of Ocaml syntax being a complete mess. Ocaml needs keyword arguments, but in SML, structural typing gives named arguments without all the extra syntax.

I find the `ref` syntax of SML much nicer to use than the mutable record syntax in Ocaml.

SML doesn't have all the dotted math operators for floats.

SML strings are immutable which lends itself to a lot of potential optimizations (and there's always byte arrays if you actually need to mutate).

Ocaml let vs let expressions are annoying to me.

SML has a standard. "The implementation is the spec" in my observation always leads to problems.

My wishlist for SML:

FIX USE COMPATIBILITY. It's intentionally not specified by the standard. This makes portable code very hard. I'd love to see an approach more like JS, but without dynamic imports (useless) and with support for something like GO_PATH plus maybe the ability to recognize and import from URLs (especially .git and .sml).

JS style template strings with interpolation (the type system is at least smart enough to convert primitives to strings) and multi-line capabilities. This would also be an easy backward-compatible way to add support for unicode. Guarantee the ability to implement them as UTF-32 with the knowledge that an advanced compiler could choose to internally represent them as UTF-16 or even Latin1 to save space (JS implementations have optimized to convert their ropes from UCS-2 to latin1 when possible with huge memory savings as even Chinese sites are 90+% ASCII).

Module Typeclasses should keep typeclasses from happening everywhere (looking at you Haskell) while still allowing them to be used for more than equality.

Unofficial first-class functor support needs to be made official.

Pick one of the 4-5 slightly different concurrency models and standardize it.

Things I want that are in SuccessorML:

Guards, "OR" shorthand, optional leading pipe in matches

Line comments

Record punning, extending, and "updating"

do declaration shorthand

So I use F# and plan to look at rust in 2021 for my "compile to native code" toolset since .net is not everywhere and .net native appears to be moving very slow to release F# to native code support.

should I consider taking a look at some description of standard ml instead of rust? It seems like rust has pattern matching and immutability which matches to F# pretty good?

My use cases are mostly desktop class machines, with optional extensions to single board computers and maybe, maybe, mobile devices of some kind. Utility programs, soap and rest web services, guis for the rest apis etc.

Are you familiar with unsafe IO?

It's used pervasively in low-level code because the idealism of monads just doesn't cut it. In my opinion, this proves that the pragmatism of side effects is a necessary evil for actually getting things done in a performant way.

Lazy evaluation has the same kind of issues. Most humans don't think that way, so performance suffers. This may be a universal problem as in my experience, Haskell doesn't have good tooling to help with this issue.

Always immutable is another large issue. Yes, there's a ton of safety in immutability and it's the right tool for MOST code. Compilers aren't prefect and there seem to be an endless stream of situations where the compiler can't figure out if it is safe to mutate "immutable" data to gain performance. For the foreseeable future, the ability to mutate can have huge performance dividends.

Finally, Haskell and it's libraries are prone to rather academic programming styles and techniques. These are amazing and beautiful. They also can be hard to grep even if you know the math. When you consider that the overwhelming majority of programmers don't know the math, it seems plain that these constructs are a detriment to pragmatic, non-academic usage.