Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Standard ML in 2020

notes.eatonphil.com

Post reply on HN
Print view View original

51–60 of 125 posts

Re: Standard ML in 2020

#51

Post by anuragsoni »

hajile wrote: post #35
wilsonthewhale wrote: post #18

As someone reasonably versed in OCaml but knows nothing about SML, what are primary differences? Given that OCaml has much better tooling and more of a community, what draws people to SML still?

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…

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

Maybe I'm missing something in SML, but OCaml has `ref` as well and it works just like SML's?

  let x = ref 0
  x := 12
  print_int !x
> 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's strings are also immutable. They have been immutable by default since 2017 and prior to that one could opt into this behavior via a compiler flag.

Re: Standard ML in 2020

#52

Post by nicoburns »

hajile wrote: post #22

StandardML really hits a nice sweet spot in language design. The syntax is super-easy to learn (The BNF for the whole fits in a mere 2 pages[0]), but contains a lot of features in that small package. Rather than tacking on functional features (eg, Java with lambdas), these features have been carefully considered and streamlined and include bits like proper tail calls and currying. You get nice bits like actually soun…

How does it compare to OCaml?

Re: Standard ML in 2020

#53

Post by eatonphil »

Sophistifunk wrote: post #50

Can anybody point me to a thorough tutorial and matching impl that will install cleanly on OSX? Or should I do it in a VM? I'd very much like to learn me some ML.

Here's a pretty recent guide someone made. More info exists on the reddit.com/r/sml/wiki page.

https://saityi.github.io/sml-tour/tour/00-00-welcome.html

Re: Standard ML in 2020

#54

Post by Sophistifunk »

eatonphil wrote: post #53
Sophistifunk wrote: post #50

Can anybody point me to a thorough tutorial and matching impl that will install cleanly on OSX? Or should I do it in a VM? I'd very much like to learn me some ML.

Here's a pretty recent guide someone made. More info exists on the reddit.com/r/sml/wiki page. https://saityi.github.io/sml-tour/tour/00-00-welcome.html

Great, appreciate it.

Re: Standard ML in 2020

#55

Post by elihu »

hajile wrote: post #39
skissane wrote: post #24

Earlier quoted context omitted.

> Despite this, the language doesn't have the academic flaws of its descendants like Haskell. Can you elaborate on what those flaws are?

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, Ha…

> 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.

It seems like you aren't very familiar with the ways Haskell programmers deal with side effects and mutation. UnsafePerformIo is sometimes needed, and there are a few common idiomatic ways to use it, but there are usually better options. What at first looks like an impenetrable wall between the IO monad and pure code is actually surprisingly permeable, just not (usually) in ways that violate expected semantics. For instance, you can read a file into a string in the IO monad and pass the string into pure code to process it. The string is lazy, so the pure code actually triggers the file to be read as it's consumed.

Another escape hatch is the ST Monad. It allows you to run imperative computations (i.e. use mutable variables and arrays) within pure code. Since the ST computations are deterministic, they don't violate any important guarantees about pure code. You can't read and write files from the ST Monad, but if you want to do array-based quicksort or something similar it's available.

Some aspects of Haskell are hard to work with. You're right that laziness introduced some performance issues that can be tedious to fix, and some of the libraries are hard to use. However, it's a perfectly reasonable tool for many general-purpose programming applications. It's not a replacement for C, but you could say the same thing about C# or Java or any other language with a garbage collector.

(edit: fixed grammar typo)

Re: Standard ML in 2020

#56

Post by hajile »

anuragsoni wrote: post #51
hajile wrote: post #35

Earlier quoted context omitted.

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…

> I find the `ref` syntax of SML much nicer to use than the mutable record syntax in Ocaml. Maybe I'm missing something in SML, but OCaml has `ref` as well and it works just like SML's? let x = ref 0 x := 12 print_int !x > 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's strings are also immutable. They have been…

You are correct that Ocaml has a ref type (though I believe it is actually a special case of a mutable record with one field). Most stuff I've run into uses mutable records more than refs (granted, I'm hardly deep into the Ocaml way of doing things). There is a small difference between an immutable record of which one property is a reference to changing data and a mutable record where the record itself changes. I prefer the first though I realize this is mostly preference.

2017 was just 3 years ago. Loads of Ocaml stuff rely on versions much, much older than that. In any case, the idea of outright changing a formerly mutable structure to an immutable one would be unthinkable in most languages due to all the breakages it is likely to cause.

Re: Standard ML in 2020

#57

Post by lmm »

Multicomp wrote: post #37

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,…

I wouldn't. Standard ML is good, but it doesn't have the momentum that Rust does, and it doesn't have much that Rust doesn't.

Re: Standard ML in 2020

#58

Post by nine_k »

stutonk wrote: post #34
skissane wrote: post #24

Earlier quoted context omitted.

> Despite this, the language doesn't have the academic flaws of its descendants like Haskell. Can you elaborate on what those flaws are?

The profusion of Category-theoric abstractions and some of the more recent purely functional norms in Haskell are like the PhD-level version of `AbstractVisitorContextFactoryBuilder` which, aside from all the unnecessary cognitive load, lead to enormous dependency graphs of the npm variety. Personally, I wonder if uniqueness types in languages like the sadly forgotten Clean (a close relative of Haskell) would have be…

I don't think there's a way to not use monads, because a ton of everyday things just work in a monadic way, things like lists, or statement sequences in presence of exceptions. I think it's wiser to admit and use these properties instead of ignoring them.

Ignoring maths that underlie computation when writing software is like ignoring math that underlies mechanics when building houses: for some time you can get by, but bigger houses will tend to constantly fall or stand a bit askew, and the first woodpecker to fly by would ruin the civilization, just as the saying goes.

Uniqueness types were a nice idea indeed. I suspect linear types (or their derivative in Rust) do a very similar thing: data are shared XOR mutable.

Re: Standard ML in 2020

#59

Post by jberryman »

hajile wrote: post #22

StandardML really hits a nice sweet spot in language design. The syntax is super-easy to learn (The BNF for the whole fits in a mere 2 pages[0]), but contains a lot of features in that small package. Rather than tacking on functional features (eg, Java with lambdas), these features have been carefully considered and streamlined and include bits like proper tail calls and currying. You get nice bits like actually soun…

> doesn't pretend the world is a pure function.

At a first approximation, Haskell pretends the world is a piece of state, not a pure function.

Re: Standard ML in 2020

#60

Post by red2awn »

I am designing a language based on OCaml/Standard ML, what are some of the problems present in these languages that can be fixed by a new design without being constrained by a spec or backwards compatibility?
Post reply on HN