6 ms·

> that tries to be a pale imitation of mathematics but gets it even wronger than Haskell Want to elaborate that? Afaik, neither of them tries to imitate mathem

• smt88 8y ago
  Couldn't Rust macros accomplish the same kinds of things as parametrized modules? Or am I totally misunderstanding how that feature of OCaml is used in the real world?
  • dan-robertson 8y ago
    Basically no. The closest thing in rust is traits. But then this is like saying that Haskell basically has ocaml functors (functions from modules to modules) as typeclasses which isn’t true. Some of what functors do can be done with typeclasses/traits. Eg a functor might take a module with a type and compare function and produce a type of maps fron that type. Meanwhile in Haskell/Rust you get the compare function from a typeclass/trait. On the other hand you can only have one trait/typeclass implementation per type which requires newtype wrapper awkwardness if you want an alternative. Another problem is that traits tend to be basically small but functors can be big. Eg let’s say you want to write an application for transferring files over various protocols. You might implement a module per protocol which would include things like the type for the configuration, how to read the config, how to make a connection, how to pool connections, how to request a file, how to get chunks of it and so on. These things may not fit so well into a nice typeclass and some Haskell people certainly don’t like typeclasses that don’t correspond to mathematical things. In ocaml the file transferring program might be based on a fuynctor applied to each protocol. A second thing rust/Haskell don’t have is a way to make a typeclass at runtime whereas one can do that in ocaml, e.g. it’s basically impossible to make a safe type for arithmetic mod n in Haskell/rust if n must be known at runtime. It is actually possible with Reflect in Haskell but that is horrific. It would be nice if one could do something like: withMod : Integral a => a -> (forall b. (Integral b, Injects a b) => b -> c) -> c withMod (m:a) f = f (Modm m) where newtype Modm = Modm a instance Num Modm where ... instance Integral Modm where ... instance Injects a Modm where inject = Modm But you can’t. On the other hand not having any way to implicitly know how to serialise or compare things in ocaml is sad.
    • smt88 8y ago
      This was really interesting and helpful. Thank you for taking the time to type it all out. You inspired me to learn OCaml because I've never thought of it as a language that's capable of expressing things that Haskell just can't.
      • chillee 8y ago
        Some other type features that OCaml has that Haskell doesn't are polymorphic variants and structural polymorphism (row types).
• mmirate 8y ago
  > Want to elaborate that? Afaik, neither of them tries to imitate mathematics. Generally speaking, "f x" instead of "f(x)" meaning function application, types not being able to serve as namespaces for functions, arguments' types in signatures being specified separately from their names, and most importantly the preference of first-class operator symbols over function- or method-calls. * * * * * For example, I find this much more difficult to read (from Hakyll): -- | Sort pages chronologically. Uses the same method as 'dateField' for -- extracting the date. chronological :: MonadMetadata m, Traversable t => t (Item a) -> m (t (Item a)) chronological = sortByM $ getItemUTC defaultTimeLocale . itemIdentifier where sortByM :: (Monad m, Traversable t, Ord k) => (a -> m k) -> t a -> m (t a) sortByM f xs = liftM (map fst . sortBy (comparing snd)) $ mapM (\x -> liftM (x,) (f x)) xs ... than if it looked like this: trait TraversableExt<Element> /* ... */ { fn sort_by_m<M: Monad, K: Ord>(self, f: impl Fn(Element) -> M<K>) -> M<Self> { self = self.map_m(|x| f(x).fmap(|key| (x,key)))?; self.sort_by_key(|(x,key)| key).map(|(x,key)| x) } } fn chronological<T: Traversible, A>(items: T<Item<A>>) -> impl MonadMetadata<T<Item<A>>> { items.sort_by_m(|i| i.identifier().getUTC(Default::default)) } (Insert grating reminder here that Rust still doesn't have monads. Haskell's notation may be poor, but its semantics are anything but.)
  • dan-robertson 8y ago
    I think saying that “f x” is in any sense more mathematical than “f(x)” is stupid. Ask a mathematician and you may find they prefer “fx”, “f(x)”, “f[x]”, “xf”, “f.x”, “x.f” (does this make oop mathematical then?), or something else entirely. Perhaps they just write f and never mention x. Using lots of operators is certainly something that could be seen as more mathematical but then I guess that makes APL much more mathematical than Haskell and ocaml and c++ and perl combined. I don’t think that counts as mathematical but it is a difference of style. For specifying signatures this is surely a style thing. In type theory, types are normally put right next to the values and so in this respect Haskell and ocaml are not mathematical. I say this is a style thing as one can write types separately from variables, next to them, or not at all. For “types not being a namespace” I’ll give you that criticism for Haskell (but also for C) and maybe for ocaml but recall the common idiom of calling all types “t” and putting them in their own modules with relevant functions. I don’t see how this is more mathematical. My general complaint is that these aren’t differences on a more/less “mathematical” spectrum. The only mathematical things are that ocaml/Haskell are closer to lots of the fashionable PLT research than C and that research is certainly mathematical. Also Haskell people tend to fetishise category theory and abstract algebra so lots of the code that’s written is sort-of mathematical. Haskell also suffers from readability problems mainly due to the people who write Haskell and what they like rather than the language itself.