The Future of Standard ML (2013) [pdf]
cs.cmu.edu
cs.cmu.edu
Use OCaml if you want easily native binaries, predictable performance and need very little in the way of well-documented, high-quality third-party libraries.
Use Standard ML if you want to learn OCaml/Haskell/F#/Scala. Why? Ultimately it comes down to usability. First off, operators (not named functions) are to programming languages as icon-only buttons are to web pages; they are completely unusable. The only reason Standard ML avoided the plague of the operators is because it's a simpler language that was used less. Second, since it's a simpler language, you get a much cleaner introduction to things like monads and modules. It makes it very simple to jump into more complex languages like Haskell or OCaml or Scala.
I work on Ponyo [0] because I want to allow people (myself) to program at a high-level in Standard ML. Furthermore, I want to promote quality and usability. Basically, every function's type is annotated and we avoid abusing operators. The current state is such that you can parse CLI args, parse/marshal JSON, serve web pages, make http requests, browse file trees, and many other ideas in the works. But the most important part about Ponyo is that it is a large, (hopefully) well-documented project that others can study to learn Standard ML (and Haskell and Scala and OCaml and F#) better.
Scala, Haskell, F#, OCaml have their place and do their jobs well. If you don't know their place or just want to get exposure to the history behind these modern languages, I recommend giving Standard ML a shot. You can get started by reading the /r/sml wiki [1] or joining #sml on Freenode.
I really enjoyed it and found it much better suited for students than other languages, especially with the book by Gert Smolka.
As it stands every year Rossberg publishes a paper on latest 1ML enhancements; Harper does the same wrt to PLT, and by proxy SML. Meanwhile, nothing's really happening AFAICT in terms of the ML torch really being taken up and carried forward (beyond OCaml and Haskell).
Perhaps a charitable donation from an SV unicorn founder or two, corporate backing of some form, or academic backing similar to EPFL for Scala could really get the ball rolling.
Moving forward we've got OCaml and upcoming modular implicits; Haskell and the new module system, Backpack; and Scala's transition to Dotty -- basically a lot to look forward to, but would love to see SML in the mix, such a beautiful language...
I mean, I know Tiobe isn't great, but the only ML-derivative I see on the top 50 is F#. ML and OCaml crack the top 100.
https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...
Also, I'm not sure what you mean by "manually pass that around". When you define a class in Haskell that inherits from a typeclass you reference that typeclass in the header of the new class. You follow the same approach in F# with interfaces.
type IEq<'a> =
abstract member eq: 'a -> 'a -> bool
let allEq (s: 'a seq) (eq: IEq<'a>) = ...
Typeclass instances are globally unique for each type, which cannot be enforced with the interface solution. If you have an ordered map type, you can be sure the Ord instance used for insertion is the same that is used for retrieval. With the interface approach, clients cannot know which instance to use since there could be multiple implementations. The Haskell approach has its own problems, such as the proliferation of newtype wrappers to manage the dispatch mechanism.
Interfaces also hide the representation of one of their arguments (the receiver) whereas typeclasses are just a dictionary of functions.
https://wiki.haskell.org/OOP_vs_type_classes#Type_classes_ar...
"Type classes are like interfaces/abstract classes, not classes itself
There is no inheritance and data fields (so type classes are more like interfaces than classes)....
For those more familiar with Java/C# rather than C++, type classes resemble interfaces more than the classes. In fact, the generics in those languages capture the notion of parametric polymorphism (but Haskell is a language that takes parametric polymorphism quite seriously, so you can expect a fair amount of type gymnastics when dealing with Haskell), so more precisely, type classes are like generic interfaces.
Why interface, and not class? Mostly because type classes do not implement the methods themselves, they just guarantee that the actual types that instantiate the type class will implement specific methods. So the types are like classes in Java/C#.
One added twist: type classes can decide to provide default implementation of some methods (using other methods). You would say, then they are sort of like abstract classes. Right. But at the same time, you cannot extend (inherit) multiple abstract classes, can you?
So a type class is sort of like a contract: "any type that instantiates this type class will have the following functions defined on them..." but with the added advantage that you have type parameters built-in, so:
class Eq a where
(==) :: a -> a -> Bool
(/=) :: a -> a -> Bool
-- let's just implement one function in terms of the other
x /= y = not (x == y)
interface Eq<A> {
boolean equal(A that);
boolean notEqual(A that) {
// default, can be overriden
return !equal(that);
}
}
I remember years ago (15 years.. jesus I'm old) discovering OCaml and I couldn't believe how terse the language was for producing native code. If anything I don't like about OCaml syntax is that it actually has an enormous amount of syntactic sugar.
My complaint with OCaml was OCamlp and the tedium of creating modules and functors. While AdHoc poly (aka type classes) is not as flexible it is IMO easier to understand, generally less verbose and slightly more elegant than OCaml modules. I'm glad they added first class modules as I recall wanting something like that a long time ago.
https://facebook.github.io/reason/
Looks like they've used it to build all kinds of stuff (including the Hack/PHP compiler).
The back, forward, reload buttons are more usable as icons than text.
When not overused, operators are similarly more usable than verbose English names.
https://www.reddit.com/r/haskell/comments/4sdkch/haskel_newb...
Operators are certainly overused in Haskell, but sometimes they make something so much more readable.
> operators (not named functions) are to programming
> languages as icon-only buttons are to web pages;
> they are completely unusable.
val list = a +: l :+ b
a ? b : c
"a +: l" calls the +: method on l with a as its argument and returns a list with a added to the start, "l :+ b" calls the :+ method on l with b as its argument and returns a list with b added to the end. "a +: l :+ b" (parsed as "(a +: l) :+ b") therefore returns a copy of l with a added to the start and b added to the end.
This is user definable, you can make operators whichever way you like (and start them with : if you want them to be right associative).
It's very flexible and you do sort of get used to libraries using it, but I'm not entirely sure that getting used to something always means it's good.
(TBH though, I use the ternary operator constantly and think nothing of it.)
もっと練習 ⍝ Practice more NB. ⍝ is a symbol for comment.
/* NB. is for comment, too. */
// Anything inside /* */ is comment, too.
# // starts a comment, too.But they're just method calls, both defined on the class of l. It is a little weird.
l.prepend(a).append(b)
l prepend a append ba.append(l).append(b)
?
[0] http://www.cse.unsw.edu.au/~chak/papers/modules-classes.pdf
Prof Milner was my first CS lecturer, many years ago. Ironically the language for that course was Pascal.
A couple of years later, he taught my class of ~20 his Calculus of Communicating Systems; I think it was the first time he tried it out on undergraduates. He was incredibly kind and patient; really interested to find out which parts of the explanation didn't work, and how he could get it across better.
I think so too. Having a solver fill in my program from the proof obligations is way too amazing. I feel like there could be a connection from high-level specification -> implementation either by proof obligation or possibly synthesis via this route.
Plus I like ML/OCaml and would be happy to see more of it in the world.
Go learn functional programming if you haven't, it will force you to look at problem with a new set of eyes!
Besides that, your "fast" code will not be as fast as it can be if you are only relying on purely functional code, at least on current architectures.
"Looks like we need to let the scholars know - there are 18,300 uses of the non-word "performant" in scholarly papers" <- If that's not sarcasm, something is wrong. Performant is a word!