Live data from Hacker News

OCaml Programming: Correct and Efficient and Beautiful

cs3110.github.io

161–170 of 251 posts

Re: OCaml Programming: Correct and Efficient and Beautiful

#161
post #51

Earlier quoted context omitted.

It doesn't look so bad to me. It's telling you that a list type was expected but you passed it a function that returns a list instead. You're right though that OCaml isn't the kind of language you can pick up in an afternoon.

Tiny quibble that I wouldn’t normally post but I think illustrates the readability issues here: Should that be “Result set type was expected”, not “list”?

Can you explain (rather than state) what readability issue you think exists here?

I don't know if you see a real readability issue or not, but I do think it's easy to jump to "hard to read" when that's only true in a certain parochial sense: it's not what we're used to.

Re: OCaml Programming: Correct and Efficient and Beautiful

#162
post #21

Earlier quoted context omitted.

OCaml vs All: Good luck finding developers that will write quality code and not cost a fortune each.

It's not getting things done that matters. It's feeling superior to others that matters.

No post body was provided.

Re: OCaml Programming: Correct and Efficient and Beautiful

#163
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…

You can add a dune-project file at the root of your project with just `(lang dune 3.2)` (or your dune version rather than 3.2). The file can also be generated by "dune init project project_name" for fresh projects.

Thanks. It looks like all I needed was the project file. I was confused because when I followed the instructions to run dune init it created an entire directory structure and then I was confused about where my code should go (I haven't gotten to the chapter on modules yet).

Re: OCaml Programming: Correct and Efficient and Beautiful

#164
post #112

Earlier quoted context omitted.

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.

Rust is a different language with a different audience. If a functional language is presented today that does not automatically curry calls, I have no interest. Just because the tool does not work for you does not mean there's a defect in the design.

I think that it is better to not forget that expressiveness comes at the cost of a richer world of misbehaving code. If you are used to a world where functions have more than one argument and must be applied to exactly the right number of arguments and nearly never returns another function, starting a curried language suddenly throws you in a situation where many small mistakes like `plus 1` are not caught early anymore. Moreover, those delayed mistake are here to allow room for an expressiveness that you are not using yet. This is a genuinely frustrating situation. And I do hope to improve OCaml type error messages to better highlight type difference at some point in the future.

Re: OCaml Programming: Correct and Efficient and Beautiful

#165

"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

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

Nah, SML does also support automatically curried function definitions, it's just that by convention that feature didn't get used as often. I tried to find out why that was the case a while ago, and stumbled on this explanation: https://www.reddit.com/r/ProgrammingLanguages/comments/jde9x...

Re: OCaml Programming: Correct and Efficient and Beautiful

#166

Earlier quoted context omitted.

With OCaml type system permanently burned in my mind, I parse that error message as "there is an ` _ -> Result_set.t ` arrow type which is not compatible with type `Result_set.t`". Do you think that the issue is that the arrow `->` is too hard to spot?

I have no insight into what is hard and what is easy to implement here, but might it be feasible to break up the error into parts, the first just as you wrote? Along the lines of: 1. Error: This expression has type ('x -> Result_set.t) list but an expression was expected of type Result_set.t list 2. where 'x = (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list The solution suggested by the parent of your post sou…

Emphasizing the arrow (or in fact the most narrow error) is definitively a good idea in that case. Counting the number of arguments is in general a bit problematic: it is possible to end with an accidental functional value due to an extra argument send to a sufficiently polymorphic function for instance.

Re: OCaml Programming: Correct and Efficient and Beautiful

#167
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.

Indeed it is :)

Dropping an example in TryOcaml[0]:

    let f : int -> int = fun _ -> 1 ;;
    val f : int -> int = 
    let ex : int list = [f] ;;
    Line 1, characters 21-22:
    Error: This expression has type int -> int but an expression was expected of type
      int

[0]: https://try.ocamlpro.com/

Re: OCaml Programming: Correct and Efficient and Beautiful

#168
post #27

I found my experience trying to work with a large OCaml base a nightmare — when signatures changed in an unstable dependency (e.g. function argument removed and nested inside another), the errors spat out by the typechecker were utterly incomphrehensible. This was largely due to automatic currying in OCaml — if I have a function call "some_function arg1 arg2" and "some_function" adds a third argument, that call becom…

This mirrors my experience in SML/NJ, where for the longest time the most common error message the compiler would spit out was 'tycon mismatch' and a Google search would not tell you what a tycon was (it's a type constructor). I think, unfortunately, I've observed a pattern in much functional programming (F# being a blessed exception) that relatively excellent computer language designers suffer from the utter ineptit…

Sadly I think SML/NJ has some of the worst messages for SML; Poly/ML and MLton both end up with something more reasonable than the dreaded

    Error: operator and operand do not agree [tycon mismatch]

Re: OCaml Programming: Correct and Efficient and Beautiful

#169
post #148

Earlier quoted context omitted.

I see, you made the beginner mistake with OCaml. You should never read the OCaml error message except if all other options failed. Try to not read those messages, but just look at the line where the error occured. You can use -annot or -bin-annot when compiling and the Tuareg function caml-types-show-type in Emacs will be your best friend.

This is old advice :-). Use the LSP server and dune and the error displays instantly, no further setup required.

I don't get it. Is it sarcasm?

Re: OCaml Programming: Correct and Efficient and Beautiful

#170

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…

> What is needed is to bridge the good things from OCaml, the type system, the pattern matching with tagged types into a modern, imperative programming languages.

Like https://rescript-lang.org/?

Post reply on HN