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

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

Post reply on HN
Print view View original

111–120 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#111

Post by shikoba »

tgflynn wrote: post #59

This is a very specific question but I thought I'd ask it here on the chance someone might have a good answer. I've been slowly working my way through this course and I ran into an issue recently when I upgraded my OCaml installation to the latest version (4.13.1). With this version I find that the simple instructions for building an executable with dune (especially one that uses OUnit) given here https://cs3110.gith…

The latest version is 4.14.0. Personally I write my Makefile myself and use them to build my projects. It works perfectly.

Re: OCaml Programming: Correct and Efficient and Beautiful

#112

Post by muglug »

ahmedalsudani wrote: post #89
muglug wrote: post #78

Earlier quoted context omitted.

> It takes a bit of time to learn to read [OCaml's error messages] Yeah, and I think you could say the same of Rust when it comes to the borrow checker's messages. But in Rust's case the problem it's trying to describe is itself pretty complex. The complexity of OCaml's error messages are really not justified by the problem they're warning you about, which is itself very straight-forward.

The ML languages started appearing in the 70s. Rust is a very modern language. Where do you think rust got (more than) half of its type inspiration from? Either way no one has to use any language. Personally OCaml is not my cup of tea--Haskell is. But it is a great tool and it's solving hard problems.

I used StandardML at university in the early 2000s, and I appreciate that OCaml is an older language that heavily influenced the design of Rust.

Given that history, it’s instructive to note the sorts of things (like auto-currying) that Rust did not inherit.

Re: OCaml Programming: Correct and Efficient and Beautiful

#113

Post by octachron »

wyager wrote: post #98
octachron wrote: post #97

Earlier quoted context omitted.

OCaml does not require more annotations than Haskell for polymorphic functions? Both language only require annotations in the case where inference would be undecidable (polymorphic recursions, higher-rank polymorphism, and GADTs). I know few cases where OCaml require less annotations than Haskell, I would expect the reverse to be true. And maps and sets are not the main use case for polymorphism in OCaml. Even taking…

> OCaml does not require more annotations than Haskell for polymorphic functions? A) I am fairly confident this is not actually true in a technical sense, although it's been several years since I've thought about it B) In any case, in the (many) instances where you (by rule or convention) need to put a type signature on your function (e.g. because it's a top-level function, one that you export, etc.), it is a pain in…

Do you have any examples? Unfortunately from my perspective, I cannot make sense of your statements.

OCaml typing is principal in all situation where type inference is decidable. The syntax for annotation for polymorphic functions is isomorphic between OCaml and Haskell.

If I take a random module in the standard library, let's say Array, 95% of the functions in this module are parametric polymorphic. I am thus genuinely puzzled by your statement that "OCaml programmers almost never write polymorphic functions".

Re: OCaml Programming: Correct and Efficient and Beautiful

#114

Post by nh2 »

muglug wrote: post #45
munchler wrote: post #34

Earlier quoted context omitted.

FWIW, F# is very similar to OCaml, but its error message in this case is usually quite clear. E.g. This expression was expected to have type 'int' but here has type 'string -> int'

yes, that would be a straightforward error message! But I got the error message Error: This expression has type ((locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t) list but an expression was expected of type Result_set.t list Type (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t is not compatible with type Result_set.t Which is not half as readable.

For comparison, in Haskell you would get for this definition:

    myfun :: Int -> Char -> Bool
    myfun a b = undefined
if you give too many arguments:

    myfun 1 'c' 3

    • Couldn't match expected type ‘t0 -> t’ with actual type ‘Bool’
    • The function ‘myfun’ is applied to three value arguments,
        but its type ‘p10 -> Char -> Bool’ has only two
if you give too few arguments:

    putStrLn (myfun 1)

    • No instance for (Show (p20 -> Bool))
        arising from a use of ‘print’
        (maybe you haven't applied a function to enough arguments?)
I like how it says

    applied to three value arguments ... but its type ... has only two
and

    maybe you haven't applied a function to enough arguments?

Re: OCaml Programming: Correct and Efficient and Beautiful

#115

Post by [deleted] »

frankohn wrote: post #104
octachron wrote: post #79

Earlier quoted context omitted.

Concerning the issue with function arguments, this is one of the reason why OCaml has labelled arguments. And for instance, Janestreet's idiom udes labelled arguments as often as possible. Similarly, I am not sure what is the issue with using imperative OCaml for imperative algorithms when they are a better fit for the problem at hand?

> And for instance, Janestreet's idiom udes labelled arguments as often as possible. So you have to give up to one of pillars of the functional programming paradigm and you get a less elegant but more practical programming language. Otherwise I agree that using labeled arguments is mostly fine and doesn't completely spoil the language. The more serious compromise to the functional programming paradigm is the fact tha…

[deleted]

Re: OCaml Programming: Correct and Efficient and Beautiful

#116

Post by toolslive »

raverbashing wrote: post #84

"beautiful" But then it has quirks like using ;; to end statements (EDIT: only in the REPL). And comments with that weird syntax But worse of all are the optional parenthesis in function calls. Yes, I know Ruby has it. But it feel super weird and a needless flexibility (that causes more confusion than it solves). I can't get over this stuff, sorry.

> worst of all are the optional parenthesis in function calls

??

    > let r = some_function x y z in ...
There are no parentheses here, and it's not optional. What you probably are missing is that if `some_function` takes 3 arguments, then `some_function x y` is a function value that takes 1 parameter (currying).

Btw, iirc, SML doesn't have this: there you only have 1 parameter but it could be a tuple

Re: OCaml Programming: Correct and Efficient and Beautiful

#117

Post by [deleted] »

octachron wrote: post #108
frankohn wrote: post #104

Earlier quoted context omitted.

> And for instance, Janestreet's idiom udes labelled arguments as often as possible. So you have to give up to one of pillars of the functional programming paradigm and you get a less elegant but more practical programming language. Otherwise I agree that using labeled arguments is mostly fine and doesn't completely spoil the language. The more serious compromise to the functional programming paradigm is the fact tha…

I am not sure which pillar of functional programming is lost with labelled arguments? Partial applications still work, higher-order function too. One might need to use anonymous functions when labels does not match but I don't see any pillar being lost. In the same way, it is perfectly possible to switch to the imperative style only in the specific code path where performance really matters and use abstraction to iso…

[deleted]

Re: OCaml Programming: Correct and Efficient and Beautiful

#118

Post by kitd »

throwaway894345 wrote: post #90
frankohn wrote: post #69

As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…

I generally agree, and I'm hoping that Gleam fits the bill for "Rust with garbage collector" (also, when I say this, people leap to OCaml, but OCaml introduces a bunch of problems which aren't present in Rust: cryptic syntax, lower quality build tooling, unbounded type inference, competing "standard" libraries, a fairly toxic community, etc).

> OCaml introduces a bunch of problems which aren't present in Rust: cryptic syntax ...

Hmm, I think "cryptic syntax" is probably in the eye of the beholder

Re: OCaml Programming: Correct and Efficient and Beautiful

#119

Post by kaba0 »

frankohn wrote: post #69

As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…

There are two ways to improve performance of a given program. You either go lower level, giving more control over the execution and specifying what you want exactly, or you go higher, not constraining the execution as much, allowing for better optimizations.

For example a manual for loop will almost always be harder to optimize than a map. The latter gives explicit permission for reordering, allowing for vectorization and parallelization automatically.

Also, I would think twice before claiming FP non-ideal for PLs - modern CPUs employ just as much FPism as they are considered imperative. OOE doesn’t sound too imperative to me. And at the end of the way, imperative steps are just sequential state changes from a different perspective.

Re: OCaml Programming: Correct and Efficient and Beautiful

#120

Post by [deleted] »

whimsicalism wrote: post #107
muglug wrote: post #45

Earlier quoted context omitted.

yes, that would be a straightforward error message! But I got the error message Error: This expression has type ((locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t) list but an expression was expected of type Result_set.t list Type (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t is not compatible with type Result_set.t Which is not half as readable.

This seems exactly the same to me just with more complicated type names.

[deleted]
Post reply on HN