Strengths of Standard ML compared with more recent FPLs
Brian Adkins
I've begun dabbling in functional programming languages and have
decided to start with Standard ML (using Robert Harper's online pdf
initially), and then possibly continue with another language. I'm
curious about possible advantages Standard ML may /still/ have over more
recent functional programming languages such as OCaml and Haskell.
If those who are proficient in Standard ML *and* a more recent FPL
could list a few bullet points, I would like to research them further
on my own. I've spent a fair amount of time on Google, but it's
difficult to get a feel for relative importance of a feature in
day-to-day programming tasks from articles alone.
--
Brian Adkins
http://lojic.com/
Jon Harrop
SML has equality types whereas OCaml lets the programmer incorrectly apply
polymorphic comparison and hashing to data structures for which they are
broken.
SML allows arithmetic operators to be applied to ints and floats whereas
OCaml uses + and +. etc.
SML has implementations like MLton that perform aggressive whole-program
optimizations (although it has a much worse code generator that ocamlopt on
x64). Xavier Leroy claims that OCaml generates faster symbolic code than
MLton but I found that MLton generated code 5x faster than ocamlopt for a
simple term rewriter that I wrote.
SML also has a much cleaner and simpler design and syntax than OCaml.
SML's main advantage over Haskell is predictable performance.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Paul Rubin
> I've begun dabbling in functional programming languages
Well, why are you doing that? Understanding your objective is useful
for answering your question.
> If those who are proficient in Standard ML *and* a more recent FPL
> could list a few bullet points, I would like to research them further
> on my own. I've spent a fair amount of time on Google, but it's
> difficult to get a feel for relative importance of a feature in
> day-to-day programming tasks from articles alone.
Importance of anything for day-to-day programming tasks is partly a
matter of personal preference and partly a matter of the specific
requirements of the day-to-day programming tasks that you happen to
work on. So you're going to have to resolve that one for yourself.
As for dabbling (i.e. treating the languages as objects of study in
their own right, rather than as mere tools), my own opinion is that
you should study the newer languages regardless of whether they are
directly useful in day-to-day programming tasks. They incorporate
more advanced ideas that will deepen your understanding of programming
and make you a more effective programmer regardless of what languages
you actually use for day-to-day work.
Michael Ekstrand
> Brian Adkins wrote:
>> I've begun dabbling in functional programming languages and have
>> decided to start with Standard ML (using Robert Harper's online pdf
>> initially), and then possibly continue with another language. I'm
>> curious about possible advantages Standard ML may /still/ have over more
>> recent functional programming languages such as OCaml and Haskell.
>>
>> If those who are proficient in Standard ML *and* a more recent FPL
>> could list a few bullet points, I would like to research them further
>> on my own. I've spent a fair amount of time on Google, but it's
>> difficult to get a feel for relative importance of a feature in
>> day-to-day programming tasks from articles alone.
>
> SML has equality types whereas OCaml lets the programmer incorrectly apply
> polymorphic comparison and hashing to data structures for which they are
> broken.
Definitely agreed (although I think that type classes are a better
solution yet).
> SML allows arithmetic operators to be applied to ints and floats whereas
> OCaml uses + and +. etc.
I agree that this is a great practical convenience. It is implemented,
however, as something of a special case in the type system which is
somewhat grating. It's almost like you have a type class in one place.
The OCaml looks warty, but the type system is at least pure in this
respect.
> SML has implementations like MLton that perform aggressive whole-program
> optimizations (although it has a much worse code generator that ocamlopt on
> x64). Xavier Leroy claims that OCaml generates faster symbolic code than
> MLton but I found that MLton generated code 5x faster than ocamlopt for a
> simple term rewriter that I wrote.
Oh, the times when I've wanted this (or at least a de-functorizer) for
OCaml.
I'll add one further small (potential) advantage: SML's records are a
touch more flexible than OCaml's. They don't require pre-declaration or
module namespacing.
In general, though, I find that OCaml's clean integration with the
surrounding world (its compiler and the programs it generate play quite
nicely as standard Unix programs, compare with the pain of generating an
executable with SML/NJ; also, it has good libraries for accessing Unix
system calls, etc.) outweigh by far the benefits I see in SML/NJ.
- Michael
Jon Harrop
> Jon Harrop wrote:
>> Brian Adkins wrote:
>>> I've begun dabbling in functional programming languages and have
>>> decided to start with Standard ML (using Robert Harper's online pdf
>>> initially), and then possibly continue with another language. I'm
>>> curious about possible advantages Standard ML may /still/ have over more
>>> recent functional programming languages such as OCaml and Haskell.
>>>
>>> If those who are proficient in Standard ML *and* a more recent FPL
>>> could list a few bullet points, I would like to research them further
>>> on my own. I've spent a fair amount of time on Google, but it's
>>> difficult to get a feel for relative importance of a feature in
>>> day-to-day programming tasks from articles alone.
>>
>> SML has equality types whereas OCaml lets the programmer incorrectly
>> apply polymorphic comparison and hashing to data structures for which
>> they are broken.
>
> Definitely agreed (although I think that type classes are a better
> solution yet).
Type classes make performance unpredictable though so I'd only want them
when they are guaranteed to be statically resolved.
>> SML allows arithmetic operators to be applied to ints and floats whereas
>> OCaml uses + and +. etc.
>
> I agree that this is a great practical convenience. It is implemented,
> however, as something of a special case in the type system which is
> somewhat grating. It's almost like you have a type class in one place.
> The OCaml looks warty, but the type system is at least pure in this
> respect.
Right. I don't think this is a major benefit for SML because it does not
apply to float32, complex, vectors and matrices.
>> SML has implementations like MLton that perform aggressive whole-program
>> optimizations (although it has a much worse code generator that ocamlopt
>> on x64). Xavier Leroy claims that OCaml generates faster symbolic code
>> than MLton but I found that MLton generated code 5x faster than ocamlopt
>> for a simple term rewriter that I wrote.
>
> Oh, the times when I've wanted this (or at least a de-functorizer) for
> OCaml.
Well, again it undermines predictable performance. I'd rather have JIT
compilation with monomorphization and manual "inline" than handles the
specialization of higher-order functions wrt their function arguments. F#
does that and it rocks.
> I'll add one further small (potential) advantage: SML's records are a
> touch more flexible than OCaml's. They don't require pre-declaration or
> module namespacing.
Hmm, not sure about this. They are certainly different but their flexibility
is offered in a better form by OCaml's objects (this is their primary
practical use). Moreover, SML's records do not always work without
predeclaration:
- fn a => #1 a;
stdIn:1.1-2.10 Error: unresolved flex record
(can't tell what fields there are besides #1)
and IIRC are a PITA for noobs because they require type annotations.
> In general, though, I find that OCaml's clean integration with the
> surrounding world (its compiler and the programs it generate play quite
> nicely as standard Unix programs, compare with the pain of generating an
> executable with SML/NJ; also, it has good libraries for accessing Unix
> system calls, etc.) outweigh by far the benefits I see in SML/NJ.
Oh, I forgot one potentially huge benefit of SML over OCaml: the PolyML
compiler for SML apparently has genuine parallel threads which OCaml
famously lacks.
Brian Adkins
> Brian Adkins <lojic...@gmail.com> writes:
>> I've begun dabbling in functional programming languages
>
> Well, why are you doing that? Understanding your objective is useful
> for answering your question.
I enjoy learning new things, but my primary motivation is to determine
if I can become more productive in a functional programming language
than I am currently. I experienced significant productivity boosts
when I transitioned from C/C++ to Java and from Java to Ruby, so I'd
like to know if I can do it again.
Also, since Ruby is currently an inefficient language, even if my
productivity only increases marginally, the runtime performance boost
could be a significant advantage.
I'm taking a long term view, so I'm more interested in the language
proper vs. the current state of libraries & ecosystem at the moment.
>> If those who are proficient in Standard ML *and* a more recent FPL
>> could list a few bullet points, I would like to research them further
>> on my own. I've spent a fair amount of time on Google, but it's
>> difficult to get a feel for relative importance of a feature in
>> day-to-day programming tasks from articles alone.
>
> Importance of anything for day-to-day programming tasks is partly a
> matter of personal preference and partly a matter of the specific
> requirements of the day-to-day programming tasks that you happen to
> work on. So you're going to have to resolve that one for yourself.
Sure, but I expect I would be able to help others identify some of the
more helpful features of programming languages I'm proficient in - in
particular as they compare to other languages.
> As for dabbling (i.e. treating the languages as objects of study in
> their own right, rather than as mere tools), my own opinion is that
> you should study the newer languages regardless of whether they are
> directly useful in day-to-day programming tasks. They incorporate
> more advanced ideas that will deepen your understanding of programming
> and make you a more effective programmer regardless of what languages
> you actually use for day-to-day work.
"Dabbling" may have been a poor word choice on my part. I'm "dabbling"
in the sense that I haven't devoted much time to the task, but I have
a pragmatic, well defined end in mind.
My impression before I posted my question was that Standard ML seemed
to be a reasonable language to learn for a first FPL, but on the other
hand, if I sensed that it might *only* be a stepping stone to another
FPL, then I may want to save time and skip it.
Paul Rubin
> I enjoy learning new things, but my primary motivation is to determine
> if I can become more productive in a functional programming language
> than I am currently. I experienced significant productivity boosts
> when I transitioned from C/C++ to Java and from Java to Ruby, so I'd
> like to know if I can do it again.
If "productivity" means measuring how long it takes you to bang out a
working small-to-medium sized program for some task, I don't think
you'll get that big an improvement going from Ruby to current FPL's.
It could be that the FPL's will give you better program reliability
because of static type systems. They will certainly give you better
performance.
> I'm taking a long term view, so I'm more interested in the language
> proper vs. the current state of libraries & ecosystem at the moment.
It seems to me that ML and OCaml are 1980's languages that haven't
changed much since then. Haskell, by comparison, is a 1990's language
with 2000's features added, giving something of a kludgy combination,
but still about the easiest way to access the latest ideas.
The only sensible long term view is that languages are going to keep
evolving and changing, and you're going to have to keep learning more
of them as they develop, in order to keep up with the times.
> Sure, but I expect I would be able to help others identify some of the
> more helpful features of programming languages I'm proficient in - in
> particular as they compare to other languages.
In this case you're asking about Ruby, which wasn't really part of the
question earlier.
> My impression before I posted my question was that Standard ML seemed
> to be a reasonable language to learn for a first FPL, but on the other
> hand, if I sensed that it might *only* be a stepping stone to another
> FPL, then I may want to save time and skip it.
That was basically the way I looked at the same question. I saw that
getting to understand ML would take some mind bending compared to what
I was used to, and getting to understand Haskell would take even more
mind bending. But if I got to understand Haskell, then going
backwards to figure out ML would be easy, while doing it in the
opposite order would require mind bending at both steps. So I went
with Haskell first.
One thing I would say is that the Freenode #haskell irc channel is a
very friendly and lively place, that makes Haskell fun to learn and
chat about. I don't know the situation for the ML channels.
Brian Adkins
> Brian Adkins <lojic...@gmail.com> writes:
> [...]
> In this case you're asking about Ruby, which wasn't really part of the
> question earlier.
I'm sorry I wasn't more clear; I'm asking about how Standard ML
compares with more recent FPLs such as OCaml and Haskell. My question
has nothing to do with Ruby.
>> My impression before I posted my question was that Standard ML seemed
>> to be a reasonable language to learn for a first FPL, but on the other
>> hand, if I sensed that it might *only* be a stepping stone to another
>> FPL, then I may want to save time and skip it.
>
> That was basically the way I looked at the same question. I saw that
> getting to understand ML would take some mind bending compared to what
> I was used to, and getting to understand Haskell would take even more
> mind bending. But if I got to understand Haskell, then going
> backwards to figure out ML would be easy, while doing it in the
> opposite order would require mind bending at both steps. So I went
> with Haskell first.
When you say "going backwards", do you simply mean chronologically, or
do you feel that Standard ML is "backwards" from Haskell with respect
to features or value? If the latter, are there specific things you
value in Haskell that you would miss if programming in Standard ML?
That's the opposite of my original question, but helpful nonetheless.
Brian Adkins
> [...]
>
> Oh, I forgot one potentially huge benefit of SML over OCaml: the PolyML
> compiler for SML apparently has genuine parallel threads which OCaml
> famously lacks.
Thanks for the info in your previous post, and I'll look into PolyML
since I'm interested in concurrency issues also.
fft1976
> SML has equality types whereas OCaml lets the programmer incorrectly apply
> polymorphic comparison and hashing to data structures for which they are
> broken.
>
> SML allows arithmetic operators to be applied to ints and floats whereas
> OCaml uses + and +. etc.
>
> SML has implementations like MLton that perform aggressive whole-program
> optimizations (although it has a much worse code generator that ocamlopt on
> x64). Xavier Leroy claims that OCaml generates faster symbolic code than
> MLton but I found that MLton generated code 5x faster than ocamlopt for a
> simple term rewriter that I wrote.
>
> SML also has a much cleaner and simpler design and syntax than OCaml.
>
> SML's main advantage over Haskell is predictable performance.
I thought you hated SML's syntax (verbosity compared to OCaml), the
fact that MLTon is too slow to compile, other SMLs are too slow to run
and the fact that the code is not very compatible among the different
implementations (so you can't use SML/NJ for development and MLTon for
final overnight compilations)
Were there improvements in SML implementations recently, or did your
opinion change?
By the way, does MLTon have concurrent GC? How about binary and text
serialization of arbitrary types?
I'd also be worried that S. Weeks works elsewhere. It seems he was a
major force in the development effort.
fft1976
> I experienced significant productivity boosts
> when I transitioned from C/C++ to Java and from Java to Ruby, so I'd
> like to know if I can do it again.
I can tell a few things from this:
You like to follow the crowd.
You probably feel at home on the JVM.
You are OK with dynamic typing.
Perhaps Clojure would be the ideal choice for you.
Paul Rubin
> > In this case you're asking about Ruby, which wasn't really part of the
> > question earlier.
>
> I'm sorry I wasn't more clear; I'm asking about how Standard ML
> compares with more recent FPLs such as OCaml and Haskell. My question
> has nothing to do with Ruby.
Oh, hmm. I think of SML and Ocaml as being basically the same modulo
some stylistic and implementation differences, while Haskell is
quite a bit further out. Here is an SML vs Ocaml comparison:
http://adam.chlipala.net/mlcomp/
> When you say "going backwards", do you simply mean chronologically, or
> do you feel that Standard ML is "backwards" from Haskell with respect
> to features or value? If the latter, are there specific things you
> value in Haskell that you would miss if programming in Standard ML?
> That's the opposite of my original question, but helpful nonetheless.
Backwards meant in the sense that Haskell is a more advanced language
than ML (I use the term ML to mean SML and Ocaml more or less
interchangeably). Haskell is harder to learn and (maybe) harder to
use, but it has deeper ideas. Specifically, its type system is much
more powerful. Typed FPL's are radically different than old fashioned
typed imperative languages like Java, or dynamic languages like Ruby.
A maybe idiosyncratic way to look at it is this: if you want to write
a Ruby program, first you do some reasoning in your head to figure out
what the program should do to accomplish your task (e.g. what kinds of
properties its data structures will have). Then you write the code,
which specifies the computational steps that the program will carry
out, and hopefully follows the reasoning that you did in your head.
You might also describe the reasoning as comments in the code, so you
can check that the reasoning and the code actually match up. But the
compiler completely ignores the comments; they're only for the
programmer to refer to.
Typed FPL's aim towards letting you encode the reasoning directly into
the program, along with the computational steps, instead of just
putting it in comments (the reasoning is expressed as types). That
allows the compiler to check the reasoning for inconsistency, and to
check that the code and the reasoning match each other, and it can
allow the compiler to figure out code based on the types, so you don't
have to write as much code yourself. I find Haskell really
interesting because it goes further in this direction than ML does.
In fact it goes about as far as it can go while still being able to
figure out most types for itself, instead of requiring you to specify
and prove them all over your program.
You might read a book on PL theory, like this one:
http://www.cs.cmu.edu/~rwh/plbook/book.pdf
Paul Rubin
> Thanks for the info in your previous post, and I'll look into PolyML
> since I'm interested in concurrency issues also.
You might also look at Erlang.
Paul Rubin
> Perhaps Clojure would be the ideal choice for you.
Clojure is just a Lisp dialect, I thought. Do you mean Scala?
Nobody
>> That was basically the way I looked at the same question. I saw that
>> getting to understand ML would take some mind bending compared to what
>> I was used to, and getting to understand Haskell would take even more
>> mind bending. But if I got to understand Haskell, then going
>> backwards to figure out ML would be easy, while doing it in the
>> opposite order would require mind bending at both steps. So I went
>> with Haskell first.
>
> When you say "going backwards", do you simply mean chronologically, or
> do you feel that Standard ML is "backwards" from Haskell with respect
> to features or value? If the latter, are there specific things you
> value in Haskell that you would miss if programming in Standard ML?
> That's the opposite of my original question, but helpful nonetheless.
ML was one of the major influences upon Haskell.
IIRC, one of the main reasons for the development of Haskell was to
replace ML as the "standard" functional language in computer science
teaching and research. The desire to replace ML stemmed from ML's strict
semantics, which are undesirable from a theoretical viewpoint.
Jon Harrop
> It seems to me that ML and OCaml are 1980's languages that haven't
> changed much since then.
OCaml wasn't released until 1996 and had new language features last added a
few months ago.
> Haskell, by comparison, is a 1990's language
> with 2000's features added, giving something of a kludgy combination,
> but still about the easiest way to access the latest ideas.
OCaml's feature list provides some obvious counter examples, like
polymorphic variants, structurally-typed objects, a higher-order module
system.
> That was basically the way I looked at the same question. I saw that
> getting to understand ML would take some mind bending compared to what
> I was used to, and getting to understand Haskell would take even more
> mind bending. But if I got to understand Haskell, then going
> backwards to figure out ML would be easy, while doing it in the
> opposite order would require mind bending at both steps. So I went
> with Haskell first.
You should learn ML.
> One thing I would say is that the Freenode #haskell irc channel is a
> very friendly and lively place, that makes Haskell fun to learn and
> chat about.
Don Stewart banned from the #haskell IRC channel before I even wrote
anything.
Jon Harrop
> Brian Adkins <lojic...@gmail.com> writes:
>> > In this case you're asking about Ruby, which wasn't really part of the
>> > question earlier.
>>
>> I'm sorry I wasn't more clear; I'm asking about how Standard ML
>> compares with more recent FPLs such as OCaml and Haskell. My question
>> has nothing to do with Ruby.
>
> Oh, hmm. I think of SML and Ocaml as being basically the same modulo
They are not. You really should learn them.
>> When you say "going backwards", do you simply mean chronologically, or
>> do you feel that Standard ML is "backwards" from Haskell with respect
>> to features or value? If the latter, are there specific things you
>> value in Haskell that you would miss if programming in Standard ML?
>> That's the opposite of my original question, but helpful nonetheless.
>
> Backwards meant in the sense that Haskell is a more advanced language
> than ML (I use the term ML to mean SML and Ocaml more or less
> interchangeably). Haskell is harder to learn and (maybe) harder to
> use, but it has deeper ideas. Specifically, its type system is much
> more powerful.
That is a misleading statement. C++ also has a more "powerful" type system
but it is clearly not as productive.
OCaml's type system is heavily geared towards extensive type inference with
features like structural object types and polymorphic variants. Features
that Haskell lacks.
Jon Harrop
> On Jul 25, 9:10 am, Jon Harrop <j...@ffconsultancy.com> wrote:
>> SML has equality types whereas OCaml lets the programmer incorrectly
>> apply polymorphic comparison and hashing to data structures for which
>> they are broken.
>>
>> SML allows arithmetic operators to be applied to ints and floats whereas
>> OCaml uses + and +. etc.
>>
>> SML has implementations like MLton that perform aggressive whole-program
>> optimizations (although it has a much worse code generator that ocamlopt
>> on x64). Xavier Leroy claims that OCaml generates faster symbolic code
>> than MLton but I found that MLton generated code 5x faster than ocamlopt
>> for a simple term rewriter that I wrote.
>>
>> SML also has a much cleaner and simpler design and syntax than OCaml.
>>
>> SML's main advantage over Haskell is predictable performance.
>
> I thought you hated SML's syntax (verbosity compared to OCaml),
I wouldn't say that I "hate" SMLs syntax but I certainly prefer OCaml's.
> the fact that MLTon is too slow to compile,
Yeah. Compiling my 100-line ray tracer with MLton still takes 7s here
because it is only burning one core.
> other SMLs are too slow to run
SML/NJ is significantly slower than ocamlopt, yes.
> and the fact that the code is not very compatible among the different
> implementations (so you can't use SML/NJ for development and MLTon for
> final overnight compilations)
That is really a tooling issue: OCaml has industrial strength tools whereas
SML does not.
> Were there improvements in SML implementations recently, or did your
> opinion change?
My opinion is the same: the benefits of OCaml outweigh the costs compared to
SML. The only point where it is close is parallelism but PolyML has such a
poor code generator (at least it did the last time I looked: 100x slower
than ocamlopt on numerical code) that it will not be competitively
performant. Also, I have been having some success writing parallel code in
OCaml recently.
> By the way, does MLTon have concurrent GC?
No.
> How about binary and text serialization of arbitrary types?
Not sure.
> I'd also be worried that S. Weeks works elsewhere. It seems he was a
> major force in the development effort.
Stephen Weeks now works at Jane St. Capital, the world's largest OCaml
employer.
Florian Weimer
> I agree that this is a great practical convenience. It is implemented,
> however, as something of a special case in the type system which is
> somewhat grating. It's almost like you have a type class in one place.
> The OCaml looks warty, but the type system is at least pure in this
> respect.
It's not if you consider <= instead of +.
Adrian Hey
Michael Ekstrand wrote:
> Jon Harrop wrote:
>> SML has equality types whereas OCaml lets the programmer incorrectly apply
>> polymorphic comparison and hashing to data structures for which they are
>> broken.
>
> Definitely agreed (although I think that type classes are a better
> solution yet).
You'd think so. The only language I'm aware of that supports these is
Haskell and it seems that the majority of Haskellers have decided that
it's perfectly OK to use any old equivalence relation as the Eq class
(==) method. So (==) may not be telling you what you think.
It probably won't surprise anyone to learn that I found myself in
complete disagreement with the majority over this issue too:
http://www.haskell.org/pipermail/haskell-prime/2008-March/002330.html
Regards
--
Adrian Hey
fft1976
So, basically, in your opinion, there is little reason to use SML over
OCaml?
By the way, I think MLTon takes 7s to compile a program of almost any
size, not just hello-world. Most of the time is spent in the
libraries. This is on par with your typical STL-using C++ code.
Mark Wong-VanHaren
>
> ...Also, I have been having some success writing parallel code in
> OCaml recently.
Would you mind telling a bit about how you write parallel code?
Using JoCaml? Your own forking and IPC?
Cheers.
Jon Harrop
The basic idea is to fork a process that takes a snapshot of the heap,
computes a result and returns it via a future. This is easily accomplished
using the following higher-order "invoke" function (derived from Thomas
Fischbacher's work) that spawns a process and returns a closure that, when
applied, blocks for the result and returns it (even if it is an exception):
let invoke (f : 'a -> 'b) x : unit -> 'b =
let input, output = Unix.pipe() in
match Unix.fork() with
| -1 -> (let v = f x in fun () -> v)
| 0 ->
Unix.close input;
let output = Unix.out_channel_of_descr output in
Marshal.to_channel output (try `Res(f x) with e -> `Exn e) [];
close_out output;
exit 0
| pid ->
Unix.close output;
let input = Unix.in_channel_of_descr input in
fun () ->
let v = Marshal.from_channel input in
ignore (Unix.waitpid [] pid);
close_in input;
match v with
| `Res x -> x
| `Exn e -> raise e
This is sufficient for coarse-grained parallelism.
You can also used shared memory parallelism by allocating a big array with:
let a =
Array1.map_file (Unix.openfile "/dev/zero" [Unix.O_RDWR] 777)
int c_layout true n in
That will then be shared between forked processes.
These techniques and a thorough analysis of their performance are described
in the OCaml Journal articles:
http://ocamlnews.blogspot.com/2008/08/fork-based-parallelism.html
http://ocamlnews.blogspot.com/2009/07/optimizing-burrows-wheeler-transform.html
The main problem is that there is no dynamic load balancing and the
technique is tricky to use (particularly because it is not well described
anywhere else). However, the huge benefits of using OCaml still make it
very alluring overall.
Mark Wong-VanHaren
(I plan to study it and give it a go.)
Cheers.
> http://ocamlnews.blogspot.com/2009/07/optimizing-burrows-wheeler-tran...
Jon Harrop
> Many thanks for your excellent reply!
> (I plan to study it and give it a go.)
Anytime. Just don't ask me to give all of my hard work away for free. ;-)
Paul Rubin
> > Oh, hmm. I think of SML and Ocaml as being basically the same modulo
> > some stylistic and implementation differences...
> They are not. You really should learn them.
I looked at http://adam.chlipala.net/mlcomp/ which I found pretty
informative. Yes there are some differences but they don't appear to
be all that large.
> > Backwards meant in the sense that Haskell is a more advanced language
> > than ML (I use the term ML to mean SML and Ocaml more or less
> > interchangeably). Haskell is harder to learn and (maybe) harder to
> > use, but it has deeper ideas. Specifically, its type system is much
> > more powerful.
>
> That is a misleading statement. C++ also has a more "powerful" type system
> but it is clearly not as productive.
I don't remember saying Haskell was more "productive" than Ocaml; only
that it's more advanced, in the sense of using ideas closer to the
current doings of the PL research community. Agda is even more
advanced than Haskell, but past the practicality barrier for most
things. I suspect Haskell is more productive than Ocaml for some
things but not others. But generally my current main method of using
FPL's to increase productivity is by "upgrading the programmer",
i.e. by increasing my level of knowledge and capability by getting
some experience with the subject, rather than worrying about immediate
deployment. I think Haskell has been more interesting than the ML's
would have been for this purpose.
> OCaml's type system is heavily geared towards extensive type
> inference with features like structural object types and polymorphic
> variants. Features that Haskell lacks.
I'm not sure what those are, but I don't particularly miss OOP in
Haskell, and polymorphic variants sound something like type classes.
I have nothing against Ocaml and could think of some applications
where I might want to use it. In general though, I have a fair amount
of experience with strict-evaluation, partly-imperative programming in
Python and Lisp, and *ML just sounds like a (maybe improved in some
ways) version of more of the same. I suppose those paradigms are
successful for good reason, but at the same time, I feel it is ok to
try something new just for the sake of trying something new. So far,
I'm happy with that approach.
The ML variant that interests me the most right now is ATS:
http://www.ats-lang.org . I'm hoping to try it sooner or later.
Jon Harrop
> Jon Harrop <j...@ffconsultancy.com> writes:
>> > Backwards meant in the sense that Haskell is a more advanced language
>> > than ML (I use the term ML to mean SML and Ocaml more or less
>> > interchangeably). Haskell is harder to learn and (maybe) harder to
>> > use, but it has deeper ideas. Specifically, its type system is much
>> > more powerful.
>>
>> That is a misleading statement. C++ also has a more "powerful" type
>> system but it is clearly not as productive.
>
> I don't remember saying Haskell was more "productive" than Ocaml; only
> that it's more advanced, in the sense of using ideas closer to the
That is a common misconception. OCaml simply provides different
state-of-the-art type system features.
> But generally my current main method of using
> FPL's to increase productivity is by "upgrading the programmer",
> i.e. by increasing my level of knowledge and capability by getting
> some experience with the subject, rather than worrying about immediate
> deployment. I think Haskell has been more interesting than the ML's
> would have been for this purpose.
Yes. I still think you should learn OCaml because it provides several useful
techniques that upgrade the programmer that Haskell does not have. Ideally,
a language would provide all of these (or at least the good ones) but, to
date, none does.
>> OCaml's type system is heavily geared towards extensive type
>> inference with features like structural object types and polymorphic
>> variants. Features that Haskell lacks.
>
> I'm not sure what those are, but I don't particularly miss OOP in
> Haskell, and polymorphic variants sound something like type classes.
Polymorphic variants are not like type classes at all. They are like
ordinary variant types but type inferred and can be open. They are useful
in practice because there is no need to write and maintain type
declarations and because there is no need to explicitly qualify the module
they come from.
Objects are useful in OCaml for a similar reason (inferred structural
types): there is no need to define class types.
This makes for much shorter code that does not have superfluous type
definitions.
> I have nothing against Ocaml and could think of some applications
> where I might want to use it. In general though, I have a fair amount
> of experience with strict-evaluation, partly-imperative programming in
> Python and Lisp, and *ML just sounds like a (maybe improved in some
> ways) version of more of the same. I suppose those paradigms are
> successful for good reason, but at the same time, I feel it is ok to
> try something new just for the sake of trying something new. So far,
> I'm happy with that approach.
You won't have much to learn then. The main problem is lack of literature
described how these more advanced techniques are actually used to good
effect. If you like, I can point you at some examples.
> The ML variant that interests me the most right now is ATS:
> http://www.ats-lang.org . I'm hoping to try it sooner or later.
ATS has some interesting-looking features but I have not had time to examine
it yet. I postponed because it uses Boehm's conservative GC.
Torben Ægidius Mogensen
> I've begun dabbling in functional programming languages and have
> decided to start with Standard ML (using Robert Harper's online pdf
> initially), and then possibly continue with another language. I'm
> curious about possible advantages Standard ML may /still/ have over more
> recent functional programming languages such as OCaml and Haskell.
- SML has a formal semantics.
- SML is simpler and "cleaner" than OCaml and simpler than Haskell.
- SML has more different compilers to choose from.
- (As mentioned earlier) SML has a better treatment of equality than
OCaml. Haskell has a completely different treatment, so which is
better is a matter of taste.
- SML has a stronger module system than Haskell and OCaml (though the
latter is similar).
But I agree that it is getting a bit "old in the tooth" and would prefer
a new language that took the best parts of SML, changed the syntax to be
less verbose and less ambiguous (though this is not a major issue) and
added concurrency and more advanced type features (linear types and type
classes). But _not_ adding OO or every feature from recent research
(which Haskell tends to do). I would still want to keep the language
relatively simple.
Torben
Jon Harrop
> - SML has a stronger module system than Haskell and OCaml (though the
> latter is similar).
Can you elaborate on this?
ISTR Xavier saying that OCaml's module system solves various problems with
SML's such as supporting incremental compilation.
Keith H Duggar
> On Jul 26, 3:00 am, Jon Harrop <j...@ffconsultancy.com> wrote:
> > Yeah. Compiling my 100-line ray tracer with MLton still takes 7s here
> > because it is only burning one core.
>
> size, not just hello-world. Most of the time is spent in the
> libraries. This is on par with your typical STL-using C++ code.
you fail:
$ system_profiler | grep Processor
Processor Name: Intel Core Duo
Processor Speed: 2 GHz
$ g++ --version
i686-apple-darwin9-g++-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
$ vi junk.cpp
$ cat junk.cpp
#include <iostream>
int main ( )
{
std::cout << "hello world" << std::endl ;
return 0 ;
}
$ time g++ -O3 junk.cpp -o junk
real 0m0.36s
user 0m0.28s
sys 0m0.05s
"The trouble with the world is not that people know too little,
but that they know so many things that ain't so." -- Mark Twain
KHD
Torben Ægidius Mogensen
> Torben �gidius Mogensen wrote:
>> - SML has a stronger module system than Haskell and OCaml (though the
>> latter is similar).
>
> Can you elaborate on this?
>
> ISTR Xavier saying that OCaml's module system solves various problems with
> SML's such as supporting incremental compilation.
It was a couple of years since I looked into it, but at that time
OCaml's module system was missing the structure sharing and type sharing
constraints from the SML module system.
Torben
Jon Harrop
>>> - SML has a stronger module system than Haskell and OCaml (though the
>>> latter is similar).
>>
>> Can you elaborate on this?
>>
>> ISTR Xavier saying that OCaml's module system solves various problems
>> with SML's such as supporting incremental compilation.
>
> It was a couple of years since I looked into it, but at that time
> OCaml's module system was missing the structure sharing and type sharing
> constraints from the SML module system.
You can "include" one structure into another. That is the idiomatic way to
extend modules in OCaml:
# module String = struct
include String
let foo = 3
end;;
module String :
sig
external length : string -> int = "%string_length"
external get : string -> int -> char = "%string_safe_get"
external set : string -> int -> char -> unit = "%string_safe_set"
external create : int -> string = "caml_create_string"
val make : int -> char -> string
val copy : string -> string
val sub : string -> int -> int -> string
val fill : string -> int -> int -> char -> unit
val blit : string -> int -> string -> int -> int -> unit
val concat : string -> string list -> string
val iter : (char -> unit) -> string -> unit
val escaped : string -> string
val index : string -> char -> int
val rindex : string -> char -> int
val index_from : string -> int -> char -> int
val rindex_from : string -> int -> char -> int
val contains : string -> char -> bool
val contains_from : string -> int -> char -> bool
val rcontains_from : string -> int -> char -> bool
val uppercase : string -> string
val lowercase : string -> string
val capitalize : string -> string
val uncapitalize : string -> string
type t = string
val compare : t -> t -> int
external unsafe_get : string -> int -> char = "%string_unsafe_get"
external unsafe_set : string -> int -> char -> unit
= "%string_unsafe_set"
external unsafe_blit : string -> int -> string -> int -> int -> unit
= "caml_blit_string" "noalloc"
external unsafe_fill : string -> int -> int -> char -> unit
= "caml_fill_string" "noalloc"
val foo : int
end
Is that what you mean by structure sharing?
I am not familiar with type sharing constraints so I cannot comment.
Torben Ægidius Mogensen
> Torben �gidius Mogensen wrote:
>> Jon Harrop <j...@ffconsultancy.com> writes:
>>> Torben �gidius Mogensen wrote:
>>>> - SML has a stronger module system than Haskell and OCaml (though the
>>>> latter is similar).
>>>
>>> Can you elaborate on this?
>>>
>>> ISTR Xavier saying that OCaml's module system solves various problems
>>> with SML's such as supporting incremental compilation.
>>
>> It was a couple of years since I looked into it, but at that time
>> OCaml's module system was missing the structure sharing and type sharing
>> constraints from the SML module system.
>
> You can "include" one structure into another. That is the idiomatic way to
> extend modules in OCaml:
>
> Is that what you mean by structure sharing?
No, structure sharing means that when you include two structures, you
can declare that same-named types in these are in fact identical types.
Otherwise, the module system will complain about ambigious names.
See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.9949
for an example of why sharing is important.
Torben
Lauri Alanko
I'd also suggest Benjamin Pierce's slides for a quick overview:
http://www.cis.upenn.edu/~bcpierce/papers/modules-icfp.ps
Lauri
raould
> described how these more advanced techniques are actually used to good
> effect. If you like, I can point you at some examples.
yes, please.
sincerely.
Jon Harrop
Look at the use of functors in the SML basis library and ocamlgraph library.
Look at the use of OCaml's structurally-typed objects in LablGTK and
compare with the verbosity of F# and WinForms or WPF. Look at the use of
polymorphic variants in LablGL.