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

What was wrong with SML?

blog.plover.com

Post reply on HN
Print view View original

21–30 of 82 posts

Re: What was wrong with SML?

#21

Post by pharmakom »

exikyut wrote: post #12
eatonphil wrote: post #8

Earlier quoted context omitted.

Yup, adoption has nothing to do with being a sensible language. More often it seems to be completely inversely related.

What are some sensible (coherent, load-bearing, force-multiplying etc) tools that have terrible adoption? Unreasonably open-ended question (suppose the scope is ML, or perhaps FP in general, or maybe even wider) - but I'm very curious.

I would say F#. It has most things you could want:

- Proper functional programming support

- Fast enough runtime

- Cross-platform and open-source

- Mainstream ecosystem

- Large corporate backer

- Compile to JS

- Commercial and open-source tooling options

… and yet C# is far more popular. This is because language adoption is driven by existing user base and other network effects NOT the quality of the language itself.

Re: What was wrong with SML?

#22

Post by jaytaylor »

shpongled wrote: post #19

SML is one of my favorite languages (I've been (very) slowly writing a compiler & language server for it). Sure, it has some warts/differences compared to newer languages - we have moved towards traits/typeclasses/etc, and I wish I could just write #[derive(Debug) - but I feel that SML fits in a very unique spot for programming languages. It's extremely simple, yet still powerful and expressive. I hope we will see co…

Is your development progress taking place in the open? (e.g. GitHub or somewhere similar)

It sounds like a cool project and I'd love to see it! And even have the option to open a PR and help ;)

Re: What was wrong with SML?

#23

Post by eatonphil »

jaytaylor wrote: post #22
shpongled wrote: post #19

SML is one of my favorite languages (I've been (very) slowly writing a compiler & language server for it). Sure, it has some warts/differences compared to newer languages - we have moved towards traits/typeclasses/etc, and I wish I could just write #[derive(Debug) - but I feel that SML fits in a very unique spot for programming languages. It's extremely simple, yet still powerful and expressive. I hope we will see co…

Is your development progress taking place in the open? (e.g. GitHub or somewhere similar) It sounds like a cool project and I'd love to see it! And even have the option to open a PR and help ;)

Yes, please share or open-source it even if it's not done!

Re: What was wrong with SML?

#24

Post by shpongled »

eatonphil wrote: post #23
jaytaylor wrote: post #22

Earlier quoted context omitted.

Is your development progress taking place in the open? (e.g. GitHub or somewhere similar) It sounds like a cool project and I'd love to see it! And even have the option to open a PR and help ;)

Yes, please share or open-source it even if it's not done!

You have already linked to it :)

Re: What was wrong with SML?

#25

Post by tialaramex »

SML was the First Language used for the Computer Science degree I took. I felt at that time, and continue to feel years later (that degree course now teaches Java as First Language) that this was a good decision despite the fact that most graduates don't end up using SML to write anything.

In the course of my education I experienced some things which I'm convinced are a bad idea even though they worked out OK for me such as selective education (whole schools only for "talented" children) and single sex secondary education, but SML as First Language is not one of those things. It worked well for me and I'm convinced it's a good idea even though I would not advocate writing new real world projects in SML unless you've got some very particular reason.

Re: What was wrong with SML?

#26

Post by shpongled »

jaytaylor wrote: post #22
shpongled wrote: post #19

SML is one of my favorite languages (I've been (very) slowly writing a compiler & language server for it). Sure, it has some warts/differences compared to newer languages - we have moved towards traits/typeclasses/etc, and I wish I could just write #[derive(Debug) - but I feel that SML fits in a very unique spot for programming languages. It's extremely simple, yet still powerful and expressive. I hope we will see co…

Is your development progress taking place in the open? (e.g. GitHub or somewhere similar) It sounds like a cool project and I'd love to see it! And even have the option to open a PR and help ;)

I have the compiler on GitHub [1] - I just started working on it again after a 2-year hiatus (to finish my PhD).

As for language-server, I'm currently sketching out some plans to use SMLnj's "Visible Compiler" feature, since that seems the easiest path forward. I have a half-baked language-server based on MLton's def-use output, but it's too unstable to share. I am planning to make some progress on the language-server in the next couple weeks.

[1] You'll notice it's just a fragment of the language for now, and only half-implemented. https://github.com/SomewhatML/sml-compiler and https://github.com/SomewhatML/sml-analyzer (again for a fragment of SML)

Re: What was wrong with SML?

#27

Post by fanf2 »

There was a history of Standard ML published as part of HOPL4 a couple of years ago - https://dl.acm.org/doi/10.1145/3386336 I was particularly interested by the more recent history, after SML '97, where there was plenty of interest in improving the language and its library, but Milner insisted that there would be no further changes, and the Definition was non-free so the others could not build on it. (It has since become Free though its source code was lost.)

Despite that there is/was an SML Basis Library project, and a Successor ML project, but it looks like even the die hard fans have drifted away https://smlfamily.github.io/

Re: What was wrong with SML?

#28

Post by bzxcvbn »

I'm not really convinced by the author's first example. While an element of type bool is an instance of type a, an element of type bool -> bool is not an instance of type a -> a.

The issue is precisely an issue of variance, which is mentioned in reference to Scala, but somehow it's glossed over. The type a -> a is covariant in its second argument, but contravariant in its first argument. As a result, you cannot "specialize" it to bool -> bool, because specialization is really another name for covariance.

Another name for contravariance is "generalization". If you ask for something of type "bool -> b", and someone provides you with some function f of type "a -> b", then you're happy. The map f is indeed an instance of "bool -> b": it can eat anything, so it can eat booleans. But with type a -> a, you cannot do what I just did: type "a" is already the most general one, and you cannot do better.

If SML accepted something of type "bool -> bool" for an instance of type "a -> a", then it was a fundamental error. But this doesn't mean that the whole thing should have been thrown out and replaced with monads. In fact, I don't really get how monads have anything to do with the problem at hand. If Haskell can prevent the following code, then I don't see why SML couldn't have prevented the authors' code:

    do m

Re: What was wrong with SML?

#29

Post by bobbylarrybobby »

> In Structure and Interpretation of Computer Programs, Abelson and Sussman describe an arithmetic system in which the arithmetic types form an explicit lattice. Every type comes with a “promotion” function to promote it to a type higher up in the lattice. When values of different types are added, each value is promoted, perhaps repeatedly, until the two values are the same type, which is the lattice join of the two original types. I've never used anything like this and don't know how well it works in practice, but it seems like a plausible approach, one which works the way we usually think about numbers, and understands that it can add a float to a Gaussian integer by construing both of them as complex numbers.

Julia uses this in pretty much all of its math functions and probably elsewhere as well, and it works unbelievably well. The type promotion system makes math Just Work, even (and especially) in the face of different-sized numbers. The result is that 99.9% of the time you simply don't have to think about the types of your numbers. Here are some examples from the docs:

  julia> promote_type(Int64, Float64)
  Float64
  
  julia> promote_type(Int32, Int64)
  Int64
  
  julia> promote_type(Float32, BigInt)
  BigFloat
  
  julia> promote_type(Int16, Float16)
  Float16
  
  julia> promote_type(Int64, Float16)
  Float16
  
  julia> promote_type(Int8, UInt16)
  UInt16
And not only are types promoted, but in well-typed Julia code, the deduction of promotion types happens at compile time instead of runtime, so there is almost no performance cost to this either.

Re: What was wrong with SML?

#30

Post by zozbot234 »

jasonhansel wrote: post #16

IMHO Haskell's lazy evaluation has some significant disadvantages compared to SML's strict evaluation. In particular, lazy evaluation makes it difficult to find the performance bottlenecks in a particular piece of code or to determine the time complexity of an algorithm just by reading it. Furthermore, subtle changes in how a function is written (for instance, making a multiplication function not evaluate the right o…

It would be nice to have a language that could treat both strict and lazy evaluation as equally first-class, as opposed to having one be the default (whether "strict" as in ML or "lazy" as in Haskell) and the other only being expressed by syntactical kludges. This may well be possible by relying on logically-inspired features like polarity and focusing, and endowing data types with strict or lazy "natural" polarities.
Post reply on HN