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

61–70 of 84 posts

Re: OCaml 4.03: Everything else

#61

Post by Tehnix »

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.

You can somewhat switch Haskell to being strict-by-default with the new Strict/StrictData pragma[0], which should be in GHC 8.0. There's also a great write-up of it here [1].

As someone else mentioned, Backpack is trying to "fix" the module system in Haskell[2], which should be interesting. That said, I don't have much of a problem with it, but then again I haven't seen the light of the OCaml way yet :)

[0] https://ghc.haskell.org/trac/ghc/wiki/StrictPragma

[1] http://blog.johantibell.com/2015/11/the-design-of-strict-has...

[2] http://plv.mpi-sws.org/backpack/

Re: OCaml 4.03: Everything else

#62

Post by catnaroek »

Tehnix wrote: post #61
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.

You can somewhat switch Haskell to being strict-by-default with the new Strict/StrictData pragma[0], which should be in GHC 8.0. There's also a great write-up of it here [1]. As someone else mentioned, Backpack is trying to "fix" the module system in Haskell[2], which should be interesting. That said, I don't have much of a problem with it, but then again I haven't seen the light of the OCaml way yet :) [0] https://g…

The real benefit of using a strict-by-default language is that laziness shows up in types. That is, I can check the type of a variable, and tell whether it's guaranteed to be a value (if it has type `Foo`), or it's a potentially still unforced thunk (if it has type `Lazy Foo`). For instance, the real type of lazy lists would be:

    data Front a = Nil | Cons a (Stream a)
    type Stream a = Lazy (Front a)
Haskell doesn't do this, not even with the Strict or StrictData pragmas.

Re: OCaml 4.03: Everything else

#63

Post by nv-vn »

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 don't know about others, but having a physical book sometimes motivates me to read it more than a digital copy would.

Re: OCaml 4.03: Everything else

#64

Post by nv-vn »

LeonidasXIV wrote: post #39
samwgoldman wrote: post #24

Earlier quoted context omitted.

I don't think that's what was meant, but rather that ocamlbuild sucks. It's not the best.

The others are even worse. I tried using OMake and apart from having some neat features like watching files and automatically recompiling it was an incredible pain of setting it up - mainly due to the strange programming language used in its build files. Also, it has seen 0 updates in the last years. It already starts with the compiler, calling them manually is quite a pain, especially if you want include any kind of…

Oasis isn't that bad apart from a few options that are tricky to get (or the fact that, as far as I know, there's no sane way to make it install executables to your ocamlfind directory, which makes it fairly unsuitable for PPX extensions). For the most part, it's about as easy/intuitive as using Cabal.

Re: OCaml 4.03: Everything else

#65

Post by nv-vn »

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…

While Idris doesn't have a module syntax, it's type system allows you to express ML modules with relative ease. It's not a great solution, but it's above Haskell in terms of this.

Re: OCaml 4.03: Everything else

#66

Post by GreaterFool »

massysett wrote: post #60
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.?

Yes, there are a lot of operations that can be implemented just in terms of bind and return. It is possible to make some functions more efficient by implementing them directly but having a generic library to fall back to would help with consistency. For instance both `lwt` and `async` are monadic, but `async` provides a richer API. I think having a generic monad library would help to bridge the gap a little bit*

* Since I am only dabbling in OCaml and only use `lwt` and `async` occasionally I'm not entirely sure. But judging by the usual structure of Haskell libraries, it should help

Re: OCaml 4.03: Everything else

#67

Post by nv-vn »

catnaroek wrote: post #56
lmm wrote: post #52

Earlier quoted context omitted.

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. (…

You could encode a module as a record with a stored type and functions for it for Idris. Then you can simply create functors as functions that take one type of record in and return another type. The syntax is ugly, but you can define macros to make it slightly more appealing. It's not an optimal approach because of namespacing of record fields, but I remember hearing that one of the next few Idris releases was going to change how record fields get namespaces.

Re: OCaml 4.03: Everything else

#68

Post by catnaroek »

nv-vn wrote: post #67
catnaroek wrote: post #56

Earlier quoted context omitted.

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. (…

You could encode a module as a record with a stored type and functions for it for Idris. Then you can simply create functors as functions that take one type of record in and return another type. The syntax is ugly, but you can define macros to make it slightly more appealing. It's not an optimal approach because of namespacing of record fields, but I remember hearing that one of the next few Idris releases was going…

ML's module language has subtyping. Given any module signature, you can obtain a supersignature by forgetting any of the following:

(0) The presence of a value component.

(1) The presence of a type component.

(2) The concrete definition of a type component, while still remembering its presence.

I am not sure you can do this in Idris, other than manually shuffling data between multiple dependent record types. Which is rather inconvenient: If you have a module with 20 components, the last thing you want to do is manually shift 15 of them to another module.

Also, unlike vanilla Haskell (no extensions) type classes, which can only have a single type parameter, ML modules can have more than one type component.

Re: OCaml 4.03: Everything else

#69

Post by LeonidasXIV »

nv-vn wrote: post #64
LeonidasXIV wrote: post #39

Earlier quoted context omitted.

The others are even worse. I tried using OMake and apart from having some neat features like watching files and automatically recompiling it was an incredible pain of setting it up - mainly due to the strange programming language used in its build files. Also, it has seen 0 updates in the last years. It already starts with the compiler, calling them manually is quite a pain, especially if you want include any kind of…

Oasis isn't that bad apart from a few options that are tricky to get (or the fact that, as far as I know, there's no sane way to make it install executables to your ocamlfind directory, which makes it fairly unsuitable for PPX extensions). For the most part, it's about as easy/intuitive as using Cabal.

Yes, I am using it too, but too bad it is basically unmaintained since its author moved to work for Google. I had hoped it could generate many more files like config for Merlin or Makefiles for build systems than ocamlbuild.

Re: OCaml 4.03: Everything else

#70

Post by thinkpad20 »

catnaroek wrote: post #30
thinkpad20 wrote: post #23

Earlier quoted context omitted.

There's one language I know that gives nearly all of those things, which is Ur (of the ur/web framework fame). Modules, type classes, eager evaluation, HKTs. It even adds features that aren't in either language such as first-class records and row polymorphism, type-level programming, macros and probably more. It's apparently very high performance, and even has a nice C FFI. The major downside is that it's only meant…

I've played with Ur/Web before, and I'm very impressed with its type system, but unfortunately I don't have much use for it, because, as you mentioned, it can only be used to make Web applications, which I don't find terribly interesting. I even remember telling Adam Chlipala on Freenode at some point in time, that it would be very nice if Ur could be used for more general-purpose programming.

Yes, I asked him a similar question a while back when I was investigating the language. I recall the response was something along the lines of that he wrote the language primarily for research into type-safe web APIs, and the language's features were a means to that end rather than an end in themselves. This is unfortunate because as a language it's one of the most exciting that I know of, but like you I have little interest in web apps.

In fact with its current compiler (AFAIK) it can only be run as a web server, which means it's not even possible to write a program which just writes Hello World to stdout and exits. This was frustrating enough to me that I soon gave up on the language. :(

Post reply on HN