I tried to build it (Ubuntu 14.04), but fails (OCaml 4.01.0) after calling make: File "types.mli", line 11, characters 14-15: Error: Syntax error make: * [types.cmi] Error 2
It builds with 4.02.
1ML – unifying ML into one language
31–40 of 63 posts
Re: 1ML – unifying ML into one language
#32Are the problems this is intended to solve problems that also affect F#?
F# doesn't even have modules; although it's derived from an ML, it has cut out rather important parts of it to make it fit into the .net ecosystem.
Re: 1ML – unifying ML into one language
#33Earlier quoted context omitted.
This actually doesn't have to do with that. They "propose a redesign of ML in which modules are truly first-class values, and core and module layer are unified into one language." They're not trying to, say, unify SML and OCaml, they're trying to solve a problem inherent to ML itself.
Can you elaborate on why these are problems for ML?
One of the classic motivating examples (which is addressed in the 1ML paper) goes like this:
Both trees and hash tables can be used to implement map-like data structures. You could, in ML, have an abstract signature for Map types that gets implemented sometimes by a concrete TreeMap implementation and sometimes by a concrete HashMap implementation. HashMap would be a better choice if the expected number of entries is larger, and the TreeMap would be better if the expected number of entries is smaller, so what we'd like to do is write something like
module Map = if size > threshold then HashMap else TreeMap
module Map = (val (if size > threshold
then (module HashMap : MAP)
else (module TreeMap : MAP))) : MAP
The motivation for 1ML is that we'd like to use the same language to talk about both modules and values. That way, we could write the first, simpler definition without having to worry about the fact that we're manipulating distinct 'things'. Of course, there are other tradeoffs involved in the 1ML solution, but it's an interesting, compelling experiment.
Re: 1ML – unifying ML into one language
#34Earlier quoted context omitted.
Can you elaborate on why these are problems for ML?
Erasing that distinction enables some goodies such as first-class type constructors, which makes it possible to manipulate types of higher kind. This in turn, presumably enables things like Generalized Algebraic Data Types.
the monad example in 1ML is:
type MONAD (m : type ⇒ type) =
{
return a : a → m a;
bind a b : m a → (a → m b) → m b
};
map a b (m : type ⇒ type) (M : MONAD m) (f : a → b) (mx : m a) =
M.bind a b mx (fun (x : a) ⇒ M.return b (f x)) (* : m b *)
This looks more flexible, but also looks like it will require more annotations and explicit parameters.
Re: 1ML – unifying ML into one language
#35Reminds me of 1Malaysia, Malaysia's political rallying call to unite multiracial Malaysia :)
Re: 1ML – unifying ML into one language
#36Are the problems this is intended to solve problems that also affect F#?
F# doesn't even have modules; although it's derived from an ML, it has cut out rather important parts of it to make it fit into the .net ecosystem.
You're not wrong, but I may phrase it differently...
F# lacks modules, instead favoring objects. Although it's derived from OCaml, it has omitted complex features which don't fit in to the .net ecosystem.
Re: 1ML – unifying ML into one language
#37I know this is not popular. I think ML has a clean syntax and simple but powerful semantics. I enjoyed coding in it. It just looks better than OCaml. Haskell is, I think, even cleaner, but there is a tendency for developers to explore the possibilities available in Haskell and then increase the complexity. It would be great to see the ML community unify and provide an offering that would give it the kind of support t…
explore the possibilities available in Haskell and then increase the complexity.
I'd caution against referring to all such explorations as complexity. Complexity is a highly overloaded term in our field. Sometimes it refers to the number of steps a given algorithm takes to compute (as a function of the input). Sometimes it refers to the depth and breadth of a program's syntax tree as well as its tendency to branch out and create cycles.
Sometimes it's mistakenly used to refer to concepts which are in reality simple but merely unfamiliar or non-intuitive. This last usage is a big problem for languages outside the mainstream which are trying to find better ways of writing software.
Re: 1ML – unifying ML into one language
#38Earlier quoted context omitted.
Can you elaborate on why these are problems for ML?
One of the classic motivating examples (which is addressed in the 1ML paper) goes like this: Both trees and hash tables can be used to implement map-like data structures. You could, in ML, have an abstract signature for Map types that gets implemented sometimes by a concrete TreeMap implementation and sometimes by a concrete HashMap implementation. HashMap would be a better choice if the expected number of entries is…
Thanks for pulling this out and explaining it; although I'm not familiar with ML, I get what the problem is here. Interesting!
Re: 1ML – unifying ML into one language
#39Earlier quoted context omitted.
Can you elaborate on why these are problems for ML?
Erasing that distinction enables some goodies such as first-class type constructors, which makes it possible to manipulate types of higher kind. This in turn, presumably enables things like Generalized Algebraic Data Types.
ocaml already has generalised algebraic datatypes as of 4.0:
http://caml.inria.fr/pub/docs/manual-ocaml-400/manual021.htm...
Re: 1ML – unifying ML into one language
#40I know this is not popular. I think ML has a clean syntax and simple but powerful semantics. I enjoyed coding in it. It just looks better than OCaml. Haskell is, I think, even cleaner, but there is a tendency for developers to explore the possibilities available in Haskell and then increase the complexity. It would be great to see the ML community unify and provide an offering that would give it the kind of support t…
explore the possibilities available in Haskell and then increase the complexity. I'd caution against referring to all such explorations as complexity. Complexity is a highly overloaded term in our field. Sometimes it refers to the number of steps a given algorithm takes to compute (as a function of the input). Sometimes it refers to the depth and breadth of a program's syntax tree as well as its tendency to branch ou…
> I'd caution against referring to all such explorations as complexity. Complexity is a highly overloaded term in our field.
The difference between complex & hard, easy & simple has been put very elegantly by Rich Hickey in Simple Made Easy [1]. That doesn't mean everyone agrees with his definitions, which is why he revives the word "complected" to mean objective interleaving of concepts, and pulls out "hard" from the way people use complex to mean something one is unfamiliar with. I like his definitions, so I use them. :)
> Sometimes it refers to the number of steps a given algorithm takes to compute
This can still create ambiguity since it could be either time or memory complexity, but still easy to infer, especially if there's a big O.
> depth and breadth of a program's syntax tree
Lisp overloads the parens for difference concepts, which is complex. This could also be hard if one's not familiar with the syntax.
> tendency to branch out and create cycles
Sounds like time complexity!
> Sometimes it's mistakenly used to refer to concepts which are in reality simple but merely unfamiliar or non-intuitive.
This is the ambiguity, is he saying Haskell complex because it has a lot of interleaving with it's concepts, that other languages do not? Or is it just unfamiliar? I would think it's simpler because it forces one to think about how time interleaves the program, which could make things harder! I'm guessing this is what the grand parent means, since ML is impure. Though, either case is empty without examples.