Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Recently I found a book, Purely Functional Data Structures and all the examples in this book are given in ML with Haskell versions in its appendix. But I only know one programming language with the functional paradigm: F#. And after a bit of research, I found out that F# is (or was) the .NET port of CAML, which is derived from ML. I've heard it mentioned that CAML is just a dialect of ML.

Given that, is it possible to translate ML to F# without a lot of knowledge of ML? What are the key differences from the languages? Or is my best bet to just learn ML instead?

share|improve this question

closed as too broad by MichaelT, Snowman, durron597, GlenH7, Ixrec Aug 15 at 10:06

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Hi Gulshan, pure "this vs. that" comparison questions are too open-ended to work here, but I think your situation is sufficiently specific to work here: I've made some modifications to your question to keep it away from just a straight abstract comparison. – user8 Oct 8 '11 at 6:59

4 Answers 4

up vote 2 down vote accepted

I'm looking at my copy of the book here and the only things I think are not directly translatable to F# would be

  • The signatures used to describe some of the generic data-types.
  • The custom notation he uses for the lazy algos.

In both cases converting should be pretty straightforward if you know F# and can understand the meaning of the book (instead of just trying to copy-paste the codes)

I also don't think you need to be afraid of not understanding the ML. I never programmed in it but got used to the style after a while and was able to get through the book just fine. The languages are quite similar specially considering this is a didactic book that doesn't rely on the tiny corner cases of the languages involved (and ML is a very solid little language!).

share|improve this answer
-1: Sorry for the downvote but I had the same assumptions until I actually tried to translate Okasaki's code to F# and it is almost impossible because he makes such extensive use of the ML module system and F# has nothing like it. You can translate the underlying code for manipulating non-abstract data structures easily enough but making them abstract and compositional is mission impossible. – Jon Harrop Feb 23 '12 at 15:25
@JonHarrop: Do you think the problem was only in doing the direct translation (due to the different module systems) or did you think there is something in the F# way of doing things that was getting in your way? – hugomg Feb 24 '12 at 0:09
Half of Okasaki's work was about composing simple collections to create bigger and better collections. This was done by parameterizing collections over underlying collections, e.g. catenable lists parameterized over the kind of queue collection they use internally. F# is incapable of this. The nearest F# is to use objects but that sacrifices type safety and, consequently, performance. In practice, the workarounds are so convoluted that real F# code almost always just hard-codes the combinations needed. The low-level code is the same though. – Jon Harrop Feb 24 '12 at 14:00

You are a bit off on what you think F# is. F# isn't a .Net port of ML anymore than C# is a .Net port of Java. F# takes a lot from OCaml (you can actually compile most OCaml code using the F# compiler).

F# also takes a more imperative approach than OCaml because of the fact it needs to in order to use the .Net framework.

Based on this SO post here are more things that F# doesn't support that OCaml does:

  • functors
  • OCaml-style objects
  • polymorphic variants
  • the camlp4 preprocessor
share|improve this answer
CAML and OCaml are two different languages I think. – Gulshan Oct 8 '11 at 7:24
@Gulshan - correct. OCaml is based on Caml. F# takes a lot from OCaml, not just plain ol' Caml. – Jetti Oct 8 '11 at 16:41
because of the fact it needs to in order to use the .Net framework -- it is probably more honest to say that there is a fundamental design decision at work here. A) Make an pure functional language B) take the easy way, because worse is better. Note that Haskell incorporates the "C framework" just fine, so does Frege with the "JVM framework". – Ingo Oct 8 '11 at 18:12
you can actually compile most OCaml code using the F# compiler - the four points you've mentioned make it quite impossible to compile OCaml using the F# compiler, especially the functors limitation of F#. – Ramon Snir Oct 9 '11 at 7:11
@Jetti: There are many other discrepancies between OCaml and F#. They don't even use the same syntax to index into arrays... – Jon Harrop Feb 23 '12 at 15:24

Given that, is it possible to translate ML to F# without a lot of knowledge of ML?

I would say not possible in this (extreme) case.

What are the key differences from the languages?

The big difference in this context is that F# doesn't have anything like ML's module system. Not only does F# not have a higher-order module system (that Okasaki uses extensively to good effect for abstraction, composition and bootstrapping) it does not even have hierarchical modules which means it is abstraction poor in comparison. You can use .NET's OOP but OOP is seriously lame compared to ML's module system.

Or is my best bet to just learn ML instead?

I would recommend learning about ML's module system if you want to understand that half of Okasaki's book. Otherwise, you can translate the low level code (not the powerful abstractions) from ML to F# in order to learn about the guts of purely functional data structures.

share|improve this answer

There's a project for this and other ML books where they have converted much of the sample code already.

It's been noted in a comment that Google Code is going read-only very soon so worth grabbing that code now. I don't think they will kill it entirely at short notice but you can't tell.

I wouldn't normally post a "link-only" answer but there's a ton of good code there to look at. (Sorry if referring to this as a "book project" mislead people).

share|improve this answer
The fundamental problem with link only answers is that they go dead. Google code for example, is going read only in under two weeks and could very well disappear all together at some point in the future. This is why it is important to fully answer the question in the answer rather than relying on external resources. If the answer requires an entire book, the question is probably too broad. – MichaelT Aug 13 at 16:20
Thanks for the prompt - hopefully my clarified answer will help. – Andy Dent Aug 14 at 7:12
It looks like Andy has copied the repo to GitHub. Thanks Andy! – Grundoon Aug 14 at 15:40
Uhh, yep, thanks for the reminder! – Andy Dent Aug 15 at 2:13

Not the answer you're looking for? Browse other questions tagged or ask your own question.