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

OCaml 4.03: Everything else

blogs.janestreet.com

Post reply on HN
Print view View original

51–60 of 84 posts

Re: OCaml 4.03: Everything else

#51

Post by catnaroek »

tome wrote: post #45
dbaupp wrote: post #44

Earlier quoted context omitted.

> In a strict language, a lazy thunk can be represented as a single mutable cell. In ML, thanks to type abstraction, the mutation is confined to the module that implements laziness, and, in the rest of the program, there's no way to tell that anything impure is happening. Unfortunately, the general story isn't quite so nice, due to thread-safety. Immutable data structures are great for thread-safety, as there's no pr…

I don’t understand what you’re saying. Haskell (specifically GHC) has perfectly thread-safe secretly mutable thunks. Are you suggesting there’s a problem with doing this in a strict language? An impure language? Or something else? I don’t see why you’d say there’s a problem with a secretly mutating thunk datatype.

He means that updates to those thunks have to be guaranteed atomic. This can be achieved in three ways: (0) disallowing threads running in parallel, (1) using atomic operations [only works on small enough pieces of data, such as pointers to boxed data], or (2) using explicit concurrency control [locks, whatever]. We know GHC doesn't do the first, and the third would also be overkill, so it probably does the second. This also explains why unboxed data in GHC is less lazy.

Re: OCaml 4.03: Everything else

#52

Post by lmm »

catnaroek wrote: post #18
mercurial wrote: post #13

Earlier quoted context omitted.

> IO is reflected in the type signature of Haskell functions. What you mean is, "effects are reflected". Haskell has a monadic effect system (IO is very rough-grained part of it), which can be combined via monadic transformers. Situations where you don't want to use OCaml: - you need good parallelism and using multiple processes are not enough (concurrency is fine, though) - you want a large pool of developers (also…

What if I want some hybrid? From OCaml, I want the awesome module system and strictness by default. (I'm not dismissing laziness or any other evaluation strategy - just saying strictness is a better default.) From Haskell, I want effects tracked in types, higher-kinded types and painless parallelism.

In order of less mainstream to more so

* Idris : modules?, strict by default, effect tracking by default, higher-kinded types, parallelism I think (at least on some platforms)

* Ceylon: modules, strictness, experimental higher-kinded types (possibly only on JS), parallelism (possibly only on Java)

* F#: modules, strict by default, parallelism

* Scala: some modularity, strict by default, higher-kinded types, parallelism

Re: OCaml 4.03: Everything else

#53

Post by lmm »

e_d_g_a_r wrote: post #31
catnaroek wrote: post #29

Earlier quoted context omitted.

On the contrary, I think OCaml's class system is potentially very confusing to someone coming from mainstream object-oriented languages. Java programmers would be confused the most, because they would have to unlearn the most. In Java, a class is a type on its own right. An object of class (and, hence, type) `Foo` has a very specific data structure, even if this data structure is unknown to the user. On the other han…

Can you provide an example of " This happens if `bar`'s type contains negative occurences of its self-type"

I guess this means contravariance, which commonly comes from having a method that accepts an argument of the same type. Consider Comparable in Java. Maybe you want to say Animal implements Comparable. But that would mean that any Animal is comparable to any other Animal - the compiler would let you compare a Cat to a Dog. Whereas really what you want to do is reuse the implementation of Animal, but Cats are only comparable to other Cats, and Dogs are only comparable to other Dogs - so Cat and Dog should inherit from Animal, but their types won't actually be subtypes of Animal. (There's no way to express this constraint in Java).

Re: OCaml 4.03: Everything else

#54

Post by woodcut »

technomancy wrote: post #48
BWStearns wrote: post #6

If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.

You can learn OCaml in a couple weeks.

Provided you had prior experience with functional languages then yes.

Re: OCaml 4.03: Everything else

#55

Post by GreaterFool »

lpw25 wrote: post #36
GreaterFool wrote: post #26

I really hope modular implicits will make it to the language one day. While OCaml libraries are no stranger to monads they usually only include `bind` and `return`. Since I'm coming from Haskell I'm used to a vast Applicative and Monad vocabulary and making do with just `bind` and `return` is rather painful. So having a generic library of Monad combinators that one could use with any Monad would be great. Also, being…

> Is there any place in the official OCaml repository / issue tracking system / wiki etc where one could check the status? You can see some things on: https://github.com/ocamllabs/ocaml-modular-implicits but you shouldn't take a lack of activity on there as a sign nothing is happening. For instance, Frederic is actively hacking on the prototype at the moment but hasn't pushed anything to that repo.

That's really great.

Re: OCaml 4.03: Everything else

#56

Post by catnaroek »

lmm wrote: post #52
catnaroek wrote: post #18

Earlier quoted context omitted.

What if I want some hybrid? From OCaml, I want the awesome module system and strictness by default. (I'm not dismissing laziness or any other evaluation strategy - just saying strictness is a better default.) From Haskell, I want effects tracked in types, higher-kinded types and painless parallelism.

In order of less mainstream to more so * Idris : modules?, strict by default, effect tracking by default, higher-kinded types, parallelism I think (at least on some platforms) * Ceylon: modules, strictness, experimental higher-kinded types (possibly only on JS), parallelism (possibly only on Java) * F#: modules, strict by default, parallelism * Scala: some modularity, strict by default, higher-kinded types, paralleli…

None of Idris, Ceylon or F# doesn't have ML-style modules:

(0) “In principle”, you could encode modules in Idris using dependent sum types, but... Good luck with that! It isn't going to be terribly usable. In general, Haskell and related languages don't consider it worth the effort to give modules proper types. I guess we can be thankful Agda's modules don't suck as badly as Haskell's - at least they can be nested.

(1) Ceylon and Scala's type systems are sophisticated enough to encode some of the use cases for modules with objects, but invariably the result is awkward. And other use cases are just impossible. For example, how should I encode an ML functor that takes as arguments two modules with shared type members? If it's possible at all, I don't even want to imagine how horrifying it will be to manually turn all the sharing by fibration into sharing by parameterization.

(2) F# doesn't allow any encoding of ML-style modules. Nothing. Nichts. Nada. It's the only so-called “ML dialect” where the most important feature from ML is completely missing.

Re: OCaml 4.03: Everything else

#57

Post by systems »

pjmlp wrote: post #38
kevingadd wrote: post #35

Earlier quoted context omitted.

Getting OCaml working at all on Windows was a hell nightmare early last year when we were setting it up for WebAssembly and that definitely soured people's opinions of it. We stuck with it because it had some dedicated fans in the working group (happily using it on linux, mostly) and it turned out to be worth the trouble, but otherwise we would have turned to some other language (F#, probably). So I'm really glad to…

I for one was quite disappointed to have bought the book "Real World OCaml" only to notice that it wasn't supported on Windows. So aside a short gig to port old Caml Light code that I had lying around into OCaml, I actually spend my ML like coding in F#.

why did you buy the book, you can read it free online

Re: OCaml 4.03: Everything else

#58

Post by baldfat »

systems wrote: post #57
pjmlp wrote: post #38

Earlier quoted context omitted.

I for one was quite disappointed to have bought the book "Real World OCaml" only to notice that it wasn't supported on Windows. So aside a short gig to port old Caml Light code that I had lying around into OCaml, I actually spend my ML like coding in F#.

why did you buy the book, you can read it free online

I usually buy online books to support the project. Not the person who bought this book.

Re: OCaml 4.03: Everything else

#59

Post by baldfat »

BWStearns wrote: post #6

If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.

I would strongly recommend looking at Racket and/or Closure. I tried the Haskell world and what a hassle to get it working on more then one machine the same way. The package management in Haskell is still more painful then other systems and is overly taxing. I work at two locations both using the same exact Dell machine with OpenSUSE and both gave problems. I also tried it on two windows machines and ugh.

OCamal also suffers from portability issues but haven't tried that hard. I love the idea of OCamal but the practical/pragmatic side of me gets rubbed the wrong way.

Personally Racket has a ton to offer and has been growing its user base a lot recently. I love this language and you can amke it whatever you want to do. Racket is a progamming language for programming languages. Clojure gives you a more pragmatic functional language and running on the jvm with a very large community.

Re: OCaml 4.03: Everything else

#60

Post by massysett »

GreaterFool wrote: post #26

I really hope modular implicits will make it to the language one day. While OCaml libraries are no stranger to monads they usually only include `bind` and `return`. Since I'm coming from Haskell I'm used to a vast Applicative and Monad vocabulary and making do with just `bind` and `return` is rather painful. So having a generic library of Monad combinators that one could use with any Monad would be great. Also, being…

"monads they usually only include `bind` and `return`"

All you need for a monad is `bind` and `return`. Is the problem that there are not polymorphic monad combinators like `sequence`, `traverse`, etc.?

Post reply on HN