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

101–110 of 125 posts

Re: Standard ML in 2020

#101

Post by cannam »

eatonphil wrote: post #17
yakubin wrote: post #15

I've recently picked it up, reading "ML for the working programmer". The language is fairly simple, everything just fits. However: 1. Both Vim and Emacs are horribly annoying with their automatic indentation for SML. There is a lot of fighting against the editor in this department. In Emacs e.g. you have to delete whitespace all the time, because otherwise you'd have top-level function definitions shifted 80 characte…

Not a huge fan of ML for the Working Programmer, personally. I'd love to see (or one day write) the equivalent of Practical Common Lisp (which itself needs an update at this point) because MftWP is sooo dated. But I can see how it's a decent enough intro. Regarding your points: 1. Yeah editor support sucks. I normally edit in text mode with my own minimal keyword highlighting or ocaml-mode. 2. Poly/ML can definitely…

I absolutely love ML for the Working Programmer, but I think you have to see it as a philosophical text as much as a tutorial.

To these points, I'd say

1. I find Emacs sml-mode is just about up to it. I do have complaints - I wish it would pull back the indentation more in lines that continue an expression, it doesn't handle multiple "where" clauses elegantly, it misaligns anonymous function alternatives - but every time I consider trying to fix them I decide they don't quite upset me enough. It's a slight pity though because I strongly believe a language should be auto-indentable (life's too short to indent code yourself), and SML is, just not quite with the existing mode.

2. I like to use Poly/ML for automatic builds during development and MLton for "production" builds - both producing executables. There are still problems on Windows, which doesn't have a properly native MLton port - the existing one uses MinGW which is ok-ish but not what I would prefer. (MLton has a code generator that produces C, so the limitation is that the runtime hasn't been ported rather than with the compiler itself.)

3. Agree, "rlwrap poly"

4. I like inline type decorations, but I also like to omit them most of the time. I think you do get some feel for when it's a good idea to add them, to clarify things for the call site or check your own intuition about the deduced types. Module boundaries (with signatures) also form a natural firebreak for out-of-control type errors.

Re: Standard ML in 2020

#102

Post by red2awn »

c-cube wrote: post #86
red2awn wrote: post #60

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?

Use utf8 strings, not utf32. It's the standard in most new languages for good reasons. Have a standard iterator type. Syntax wise, something closer to rust would help newcomers (see ReasonML maybe).

Do you think it make sense to include a character type that is basically a variable-size utf8 extended grapheme cluster?

Re: Standard ML in 2020

#103

Post by tsm »

I learned Common Lisp in high school and took a course called "Discrete Math and Functional Programming"[0] my freshman year of college (the prof wrote the textbook). To me it felt like a math course (covering predicate logic, sets, graphs, and eventually the lambda calculus. It was also the first time I had to write proofs outside of geometry class), but all of the teaching was paired with examples in ML. For example, half the homework one day would be writing proofs about powersets, and the other half would be writing ML functions to create and manipulate powersets.

It was a really neat idea, and it felt like ML got out of the way and just let me program without having painful syntax or semantics. That said, my biggest ML programs would be five functions spanning ~30 lines loaded into an smlnj interpreter. I never got to deal with functors and modules and who knows what else, and am sorry that I don't know how to "program in the large" in ML. I'm now a professional Clojure dev and would love to see how ML does things.

I own a copy of ML for the Working Programmer (which I see @eatonphil is panning below) and the ML compiler book by Appel, neither of which I've read. Maybe I'll make the time one of these months…it'd be nice to have a Motivating Project though.

0: https://cs.wheaton.edu/~tvandrun/dmfp/

Re: Standard ML in 2020

#104

Post by marcosdumay »

jberryman wrote: post #59
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.

To be a bit pedantic (because this thing is interesting), it's more like a context. In Haskell you'll say "this code must run on the real world".

Mercury literally pretends the world is a piece of state. You explicitly say "Here, run this code. The world before it runs is on variable `a`, place the world after it runs on variable `b`".

Re: Standard ML in 2020

#105

Post by dtornabene »

eatonphil wrote: post #17
yakubin wrote: post #15

I've recently picked it up, reading "ML for the working programmer". The language is fairly simple, everything just fits. However: 1. Both Vim and Emacs are horribly annoying with their automatic indentation for SML. There is a lot of fighting against the editor in this department. In Emacs e.g. you have to delete whitespace all the time, because otherwise you'd have top-level function definitions shifted 80 characte…

Not a huge fan of ML for the Working Programmer, personally. I'd love to see (or one day write) the equivalent of Practical Common Lisp (which itself needs an update at this point) because MftWP is sooo dated. But I can see how it's a decent enough intro. Regarding your points: 1. Yeah editor support sucks. I normally edit in text mode with my own minimal keyword highlighting or ocaml-mode. 2. Poly/ML can definitely…

Just want to push back a bit and leave a dissenting view on ML for the Working Programmer. If one actually works their way through the text, by the end they will have written a basic interpreter for the lambda calculus, and a small tactics oriented theorem prover, either one of which is highly illuminating to someone who hasn't done this before. The text may not educate a reader on dependent type theory or similar developments but I'm struggling to understand how it is otherwise "dated". Other than that thank you for keeping SML in front of people, I for one appreciate it, its probably my favorite language these days

Re: Standard ML in 2020

#107

Post by fanf2 »

marcosdumay wrote: post #104
jberryman wrote: post #59

Earlier quoted context omitted.

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

To be a bit pedantic (because this thing is interesting), it's more like a context. In Haskell you'll say "this code must run on the real world". Mercury literally pretends the world is a piece of state. You explicitly say "Here, run this code. The world before it runs is on variable `a`, place the world after it runs on variable `b`".

The classic paper Imperative Functional Programming https://www.microsoft.com/en-us/research/publication/imperat... introduced the IO monad and explained that its internals are based on passing around the state of the world. The monad hides the world and keeps it linear. The compiler (ghc) optimizes out the world so that it is implicit in the compiled program. I believe this is still the way that ghc works.

Re: Standard ML in 2020

#108

Post by e12e »

cannam wrote: post #101
eatonphil wrote: post #17

Earlier quoted context omitted.

Not a huge fan of ML for the Working Programmer, personally. I'd love to see (or one day write) the equivalent of Practical Common Lisp (which itself needs an update at this point) because MftWP is sooo dated. But I can see how it's a decent enough intro. Regarding your points: 1. Yeah editor support sucks. I normally edit in text mode with my own minimal keyword highlighting or ocaml-mode. 2. Poly/ML can definitely…

I absolutely love ML for the Working Programmer, but I think you have to see it as a philosophical text as much as a tutorial. To these points, I'd say 1. I find Emacs sml-mode is just about up to it. I do have complaints - I wish it would pull back the indentation more in lines that continue an expression, it doesn't handle multiple "where" clauses elegantly, it misaligns anonymous function alternatives - but every…

> 2. I like to use Poly/ML for automatic builds during development and MLton for "production" builds

Do you have/use any dependencies? Like a http/2 (or tls capable) web server, a database client or a gui library? If you do, how does that work with two implementations - if not... What kind of programs do you write/problems are you solving?

Re: Standard ML in 2020

#109

Post by eatonphil »

dtornabene wrote: post #105
eatonphil wrote: post #17

Earlier quoted context omitted.

Not a huge fan of ML for the Working Programmer, personally. I'd love to see (or one day write) the equivalent of Practical Common Lisp (which itself needs an update at this point) because MftWP is sooo dated. But I can see how it's a decent enough intro. Regarding your points: 1. Yeah editor support sucks. I normally edit in text mode with my own minimal keyword highlighting or ocaml-mode. 2. Poly/ML can definitely…

Just want to push back a bit and leave a dissenting view on ML for the Working Programmer. If one actually works their way through the text, by the end they will have written a basic interpreter for the lambda calculus, and a small tactics oriented theorem prover, either one of which is highly illuminating to someone who hasn't done this before. The text may not educate a reader on dependent type theory or similar de…

I see your point. I guess it's just the title that has turned me off even after reading the book.

It doesn't seem to send the right message these days if the idea is that working programmers are building lambda calculus interpreters or theorem provers? Even interpreting a lisp would seem more practical.

I think Practical Common Lisp was more in the right track for content but today I'd focus more explicitly on language design or backend system design.

Andrew Appel's book does already fill the language design slot though nicely.

Re: Standard ML in 2020

#110

Post by Joker_vD »

hajile wrote: post #89
Joker_vD wrote: post #66

Earlier quoted context omitted.

> Module Typeclasses should keep typeclasses from happening everywhere (looking at you Haskell) while still allowing them to be used for more than equality. I was under impression that Haskell's typeclasses plus a couple of most common extensions minus the namespace pollution are pretty much equivalent to ML modules+functors, so could you elaborate how exactly that should work?

Yes and no. They can do the same thing, but with varying amounts of effort. SML has what is essentially a hard coded typeclass for equality with special syntax for it as well (two single quotes instead of one). There can also be issues creating and overloading operators. There's still ongoing discussion about modular typeclasses for SuccessorML Here's some info if you're interested. https://www.cs.cmu.edu/~rwh/papers…

Yeah... not only the fact that SML modules always left an impression of arbitrariness (SML97 and OCaml have some subtle semantic differences and neither of those choices seem to be inherently wrong), but also the sheer complexity of their theory compared to Hindley-Milner... seems that there just has to be a better way.
Post reply on HN