Daniel Carrera writes:

Marcin,

Are you sure that OCaml is similar to Haskell? At first glance, it doesn't even look functional. It looks like an imperative language.

It's not purely functional, but it supports algebraic types and first-class functions, uses similar conventions in the library (immutable Lisp-style lists, tuples, currying), has a similar type system to Haskell's one (or rather the other way around: ML invented it), has a similar syntax (function application as juxtaposition, pattern matching, one namespace for values which include functions), neither language supports implicit type conversions nor RTTI. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/

On Tue, 3 May 2005, Marcin 'Qrczak' Kowalczyk wrote: ...

Its type system has some interesting features: polymorphic variants, parametric modules, labeled and optional arguments, objects, variance annotations of type parameters used for explicit subtyping.

It has more convenient exceptions: the exn type can be extended with new cases which look like variants of algebraic types.

There is camlp4 for extending the syntax or changing it completely.

I have been able to build ocaml everywhere I have wanted it, including the native code compiler. I suppose this isn't so much a feature of Objective CAML (the language) as ocaml (the implementation), but given the choice of a language I can actually use on a given platform, I am predisposed to have a soft spot for its other virtues like predictable execution and a relatively rigorous OOP model when you want it. Donn Cave, donn@drizzle.com

Marcin gives a good capsule description of the differences between ocaml and haskell. Let me add my two cents. I also learned ocaml before learning haskell, and the biggest single difference I found is that haskell is a lazy, purely functional language and ocaml is a strict, "mostly functional" language. So all the IO monad stuff in haskell doesn't exist in ocaml -- writing imperative code in ocaml is much like writing imperative code in C, albeit with different syntax. This makes it much easier to transition to for C or python programmers, but it's easy for side-effects to work their way into your program without you realizing it, which means you lose a lot of the advantages of functional programming -- unless you take a lot of care to make sure that most of your functions are in fact purely functional (and the compiler won't help you with that). Another big difference between ocaml and haskell is that haskell has type classes and ocaml does not. You can't imagine how great type classes are until you start using them. They mirror so much of what you intend a function to be in the type of the function, and they also allow you to use functions in a much broader domain than you would expect. Basically (if you don't know this already), type classes give you overloading of functions and operators on new data types, all done at compile time. Ocaml, in contrast, has "functors" which allow you to create customized versions of data structures parameterized on almost anything, but the data structure you create is a full module. This is also pretty elegant, but IMO is much more heavyweight and doesn't have the syntactic advantages of haskell's type classes. Since ocaml doesn't have monads at all, a lot of the more advanced monadic programming that haskellers like to do is much more cumbersome to do in ocaml. However, the biggest advantage that ocaml has over haskell is that for most applications, an ocaml program will run faster, perhaps a lot faster, than an equivalent haskell program (although the haskell program may be much smaller, have fewer bugs, be prettier, etc.). That's because lazy evaluation in haskell requires the system to wrap closures around unevaluated code and evaluate it later. This has a cost, and it simply isn't there in ocaml. If you find functional programming *completely* baffling, learning haskell off the bat is like jumping into the deep end of the swimming pool. Learning a language like ocaml first can be a good stepping stone to haskell, since many of the core concepts (like algebraic data types) are basically the same. Scheme is another great language to learn FP from, preferably in conjunction with a good textbook like _How to Design Programs_ (http://www.htdp.org) or _Structure and Interpretation of Computer Programs_ (http://mitpress.mit.edu/sicp). My progression was scheme -> ocaml -> haskell, which was nice because I didn't have to add nearly as much new material at each stage as I would have had to had I learned e.g. haskell before learning scheme or ocaml. Mike

From: Marcin 'Qrczak' Kowalczyk Mail-Followup-To: haskell-cafe@haskell.org Date: Tue, 03 May 2005 20:38:14 +0200

John Goerzen writes:

...

I'd say that there are probably no features OCaml has that Haskell lacks that are worth mentioning.

Its type system has some interesting features: polymorphic variants, parametric modules, labeled and optional arguments, objects, variance annotations of type parameters used for explicit subtyping.

It has more convenient exceptions: the exn type can be extended with new cases which look like variants of algebraic types.

There is camlp4 for extending the syntax or changing it completely.

OTOH Haskell provides type classes, better integrated arbitrary precision integer type, type variables with kinds other than *, polymorphic recursion, much better FFI, and with GHC extensions: universal and existential quantifiers in function types (OTOH OCaml recently got universal quantifiers in record fields), GADTs, implicit parameters, template Haskell.

-- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

There is also Template Haskell vs MetaOCaml. For the life of me, I still cannot fathom why Template Haskell is untyped, while MetaOCaml is fully typed. Which is the main reason I write meta-program in MetaOCaml and 'other' programs in Haskell. There is the additional aspect that my meta-programs tend to be functional, but the programs they write are imperative. That is easy to do in MetaOCaml, and I am still daunted by the idea of getting Template Haskell to do the same! Jacques

Duncan Coutts wrote:

On Wed, 2005-05-04 at 18:29 -0400, Jacques Carette wrote:

...

There is also Template Haskell vs MetaOCaml.

For the life of me, I still cannot fathom why Template Haskell is untyped, while MetaOCaml is fully typed. Which is the main reason I write meta-program in MetaOCaml and 'other' programs in Haskell.

The reason for this is that Template Haskell is more powerful and correspondingly harder to type so it is currently untyped.

``more powerful'' meaning that it can do some level of introspection, right? I know introspection can be very powerful (I designed Maple's modern reflection and reification facilities...), but I was under the impression that type systems that can handle 'too much' introspection were unsound [a result of Walid Taha].

The main reason it is more porwerful is that TH allows you to pattern match on the abstract syntax of a quoted expression and perform arbitrary transformations on that. It would be hard to preserve the well-typedness of the AST and still allow arbitrary transformations.

Can't this be regarded as a 'convenience' rather than as actual extra power? Using an abstract interpretation formalism (see papers of Taha and co-authors), it is possible to 'lift' the type of code values into staging-time terms, and pattern-match on that instead. Then well-typedness of transformations is much easier to show. In this way one can even implement some transformations that are equivalent to what are currently 'hints' to GHC as well-typed code [I have some code that does this, but there are only hints of this in a preprint of mine -- see the conclusion section of "*Gaussian Elimination: a case study in efficient genericity with MetaOCaml"* http://www.cas.mcmaster.ca/%7Ecarette/publications/ge.pdfavailable from http://www.cas.mcmaster.ca/~carette/publications.html for some hints on how this is done

A colleague of mine is currently developing a type system for Template Haskell that should catch most errors without restricting too much the programs you can write.

I am eagerly awaiting this! Writing Monadic meta-programs in MetaOCaml is feasible, but the lack of native support for Monads makes it significantly harder. But after spending 12 years writing programs in a fully dynamically typed language (Maple), I am much happier writing *all *parts of my programs in a strongly typed language! Jacques

On Wed, May 04, 2005 at 12:40:13PM +1000, Erik de Castro Lopo wrote:

That leaves one aspect of Haskell vs Ocaml I don't yet understand. What are the advantages of lazy evaluation?

The advantage of lazy evaluation is that evaluation order becomes one less thing you have to think about. The disadvantage of lazy evaluation is that evaluation order becomes one more thing you have to think about. Andrew

G'day all. On Tue, 3 May 2005 21:04:46 -0700 Andrew Pimlott wrote:

...

The advantage of lazy evaluation is that evaluation order becomes one less thing you have to think about.

Quoting Erik de Castro Lopo :

Yes, but only if your functions are pure.

Right.

...

The disadvantage of lazy evaluation is that evaluation order becomes one more thing you have to think about.

Yes, but only if your functions are impure.

Wrong. An unevaluated thunk can, in general, be much larger than what the thunk evaluates to. (Think of "length" of a large list, for example.) If such a thunk is unevaluated but not garbage for a considerable time, then you have a space leak. So you do need to think about evaluation order. One good rule of thumb is: On large data structures, try to have a single consumer only. Cheers, Andrew Bromage

Translated a bit: With lazy evaluation, the order of evaluation is irrelevant as far as the _correctness_ of the function is concerned. However, it's much easier to reason about the _efficiency_ of functions when the language uses strict evaluation; you never have to scratch your head and ask "I wonder under what circumstances will that bit of code get executed, and what will that do to the average running time of this function?" Lazy evaluation does make some kinds of idioms possible that are much harder to do with strict evaluation. For instance, here is an infinite list of ones: let ones = 1 : ones and here is an infinite list of integers: let ints = 1 : map (1+) ints Defining these doesn't cause the language to go into an infinite loop, because the contents of these lists aren't generated until they're needed. Similarly, it's easy to define an infinite list of e.g. prime numbers. Ocaml has a "lazy" module that makes it possible to do things like this, but it's much more cumbersome. Another (non-obvious) "benefit" of having lazy evaluation is that it forces the language to be purely functional. Lazy evaluation doesn't play well with side effects. Mike

Date: Tue, 3 May 2005 21:04:46 -0700 From: Andrew Pimlott

On Wed, May 04, 2005 at 12:40:13PM +1000, Erik de Castro Lopo wrote:

...

That leaves one aspect of Haskell vs Ocaml I don't yet understand. What are the advantages of lazy evaluation?

The advantage of lazy evaluation is that evaluation order becomes one less thing you have to think about. The disadvantage of lazy evaluation is that evaluation order becomes one more thing you have to think about.

Andrew _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

That leaves one aspect of Haskell vs Ocaml I don't yet understand. What are the advantages of lazy evaluation?

I'd recommend this paper (once again): http://www.md.chalmers.se/~rjmh/Papers/whyfp.html One of the main points of the paper is that lazy evaluation enables a new way of modularizing code.