i love ocaml, i love ml languages, and i think ocaml is a very good ml
but, i think its kinda too late for it, i think people who want to program with types today most likely will go to rust, scala or f#
ocaml is very niche
In haskell you can just say `show a` as long as `a` is of a type that implements the `Show` typeclass, but OCaml currently has no good answer to this. You end up with `Int.to_string a` or what-have-you. It isn't less powerful, technically, just more verbose.
Modular implicits allow you to define a function `show : (S : sig type t show : t -> string end) -> S.t -> string` and then mark the first argument implicit, so you can call `show a` and the compiler fills in the first argument with the appropriate module for the type of `a`.
There are proofs that this particular feature of typeclasses is impossible to put into OCaml's module system (something to do with functors and type aliasing and not being able to ensure that there is a unique `Show` instance per type), but modular implicits come close.
[0] The paper gives set-union as an example.
[1] https://www.youtube.com/watch?v=hIZxTQP1ifo . (Sorry for throwing video at you -- there's probably a write-up somewhere, but I'm in a bit of a rush, and this was the thing that came to mind.)
Now we just need a Haskell compiler which actually bothers to provide the "pretty essential for sanity" for global uniqueness. Currently, I count zero compilers in common use which do.
(EDIT: Just to forestall the inevitable: Yes, there are some weird and dangerous extensions you can enable, but mostly it's pretty clear that they're dangerous. It doesn't seem to be a problem in practice.)
Because they never bothered to actually implement the checks to guarantee global uniqueness in GHC?
> (EDIT: Just to forestall the inevitable: Yes, there are some weird and dangerous extensions you can enable, but mostly it's pretty clear that they're dangerous. It doesn't seem to be a problem in practice.)
No weird and dangerous extensions in use. Vanilla Haskell.
Sure they did. Orphan instances are detected by the compiler.
Orphan warnings tell you that you defined an instance in the wrong place.
Things you don't receive warnings for:
- Defining the same instance twice.
- Having code which uses both instances.
Sorry, orphan warnings are multiple magnitudes of escalation levels away from what should happen and are focused on something different (code hygiene vs. THIS-CODE-IS-WRONG-AND-BROKEN-AND-WILL-CORRUPT-SHIT-AT-RUNTIME-I-WILL-FAIL-TO-COMPILE-THIS).
I believe I've understood the issue, but if I've misunderstood then I feel extra need to comment, that my misunderstanding might be clarified.
From my first reading of what you'd written, tome seemed spot on.
On careful re-examination (after reading this comment), I think when you said "Things you don't receive warnings for:" you did not mean to say that you can write that code and receive no warnings (a reasonable interpretation), but that the warnings would not read as directed at the points you raise (also a reasonable interpretation) - which (you note) are substantially more important than "this is generally a good idea."
I claim that if you never have orphan instance warnings then your code has "the guarantees Kmett keeps boasting about". In particular you can never "define the same instance twice", and this of course implies that you cannot "have code which uses both instances".
What exactly is your complaint and why does my claim not address it?
I think the biggest issue with OCaml for mainstream adoption is the syntax, honestly.
I don't care about the minor issues, but about the major ones; the ambiguities concerning ;, if and match; essentially, as soon as you're using imperative features (which often result in using ;), you have to be very careful to make sure your code means what you think it means.
Indeed, a barrier in itself, after working through RWO I was impressed with the language, clearly very powerful, but some aspects of the language are syntactically unpleasant.
Yes, yes, semantics, not syntax, but new comers will come in all forms, including those who will just say no based on the general "look" of the language. IMO, if OCaml had the same power but looked more like SML it would have much greater adoption.
Anyway, modular implicits and multi-core will certainly help OCaml to grain traction, syntax notwithstanding.
Scala "implicits" mean two different things:
1) implicit conversions. e.g. If there is an implicit def f(x: Int): String = x.toString in scope, then any time you try to use an Int where a String is expected, Int::toString will be called automatically. Using implicit conversions like this is generally frowned upon and also where the "please no" probably comes from.
implicit conversions are used frequently but almost entirely for extension methods (there's even sugar for it now: "implicit class")
2) implicit parameters. These are parameters in a functions type signature keyed by type. You can emulate Haskell typeclasses (sans canonicity) with these. For instance
def monoidSum[A](as: List[A])(implicit m: Monoid[A]): A = as.foldLeft(m.zero)(m.append)
is equivalent to the Haskell
monoidSum :: (Monoid a) => [a] -> a
monoidSum as = foldl' mappend mempty
Scala implicit parameters can be defined inductively and depend on other implicit parameters. You can do this to perform some really cool type-level computation. The shapeless library is full of stuff like this. Once you understand implicit parameters, it really is somewhat nice to write functions that operate on arbitrarily-sized HLists and Coproducts.
Modular implicits are similar to (and inspired by?) Scala implicit parameters.
The closest I've been able to get is Oasis+OPAM, but it's just not the same.
Didn't think of it that way. Well-put and I totally agree. So odd that one hits that sweet spot in design yet gets almost no uptake. Whatever problems like OP posted need to get solved because interesting and useful things are sure to come from mainstream attention to it. Useful even outside Ocaml given its influences on other languages.
Another thing is the compiler. It's reportedly easy to understand and robust compared to most. I recall reading Esterel's report on DO-178B certifying their code generator written in Ocaml. They had to do source-to-object-code equivalence. They said that, very unusually, the Ocaml toolchain was well-structured to the point they only need minor tweaks to get the job done.
So, great language design plus great implementation equals great opportunity for robust, app development. The concurrency situation is ridiculous, though. Even C-like languages and Haskell have safe concurrency techniques. They need to get on that shit cuz nobody uses single-core boxes anymore unless they're a small shop licensing Oracle. ;)
I'm a Scala dev. I'm playing with Rust for lower level stuff, don't know much about F#, but FWIW I would rather code in Ocaml than Scala.
At my previous job I tried to introduce some functional languages without much success. The stack was C++/Java and a lot of Python. I learned Scala because it runs on the JVM and I thought that may help.
Later I moved to another city and when looking at job offers I saw a few Scala offers (and no Ocaml in sight) so I settled on Scala.
IMHO Scala gained traction because it runs on the JVM. It's easier to train Java devs because you can start by writing Java-in-Scala and incorporate specific features as you go. The web ecosystem is nice (at work we're using Play.) There's also a few killer apps, like Spark.
I'm currently trying to become as proficient in Ocaml as I am with Scala, but I'm already working with Scala 8+ hours a day so it's not that easy.
The key difference for me is "is there a polished development environment where I can get from zero to debugging within minutes".
From my perspective Mirage is OCaml's 'killer app' (I'm sure others would disagree). Where I could see it excelling is as an open-source home server platform. I'm not sure what the current progress is but I know some of the Mirage developers were working on this particular use case, I'll see if I can find the link.
Could something like Mirage exist for F#? It could, though the Mirage team have a considerable head start.
EDIT: The project I was referring to before is Nymote: http://nymote.org/
Haskell has higher-kinded type parameters and Idris has dependent types. But SML and OCaml don't even have typeclasses at all, much less higher kinds.
Furthermore, what makes Rust's type system interesting isn't just its use of regions (which the ML Kit used); it's regions combined with inherited mutability plus the borrow check to maintain soundness.
GHC 8.0 almost has dependent types and the expectation is feature completeness in 8.2, thought what's in 8.0 is already useful.
I like and use Rust and the design decisions that led to a very capable region system that allows one to write data race free and memory correct code is excellent. Haskell doesn't have such a thing because it doesn't try avoid GC.
I didn't do a point by point comparison of Rust expressiveness vs Haskell recently, but I don't remember it being close. Rafael might need to write a Rust for for Haskellers as an update of his "for OCamlers" post a while back.
It is a bit outdated but as far as I can see not inaccurate yet. I only plan to update it when HKTs make it to Rust.
There is a fun library[0] with a pretty good paper[1] on how to do that in OCaml :-)
[0]: https://github.com/ocamllabs/higher
[1]: https://ocamllabs.github.io/higher/lightweight-higher-kinded...
OCaml has a powerful module system, labeled and optional function parameters, row polymorphism, equirecursive types, and GADTs. Most of these features would be fairly difficult to add to Rust.
OCaml also has a better track record with soundness issues than Rust, and more interesting fragments of the language have been formalized.
... is this what you mean?
I revere Harper, but his anti-Haskell rants just seem unhinged to me.
I've heard bad things about Harper, but then he's an accomplished fellow, which doesn't mean he has to be nice. I only expect him to be truthful, is all. Maybe he's just ML's LISP zealot like the now deceased Dane whose name I forgot.