[Caml-list] Observations on OCaml vs. Haskell

[Caml-list] Observations on OCaml vs. Haskell

[John Goerzen]

I recently decided I ought to learn a bit about Haskell.  I've done so, 
and while it is remarkably similar to OCaml in many ways, there are a 
few things I really like about Haskell.  At first glance, to this 
relative latecomer to both languages, the Haskell approach to these 
things looks very appealing.  I am wondering if you know of drawbacks 
of their approach, and why the OCaml designers opted for something 
different.

1. Haskell lists resemble OCaml Streams

This is, in fact, one of my main complaints about OCaml lists: that they 
are a distinct type from OCaml streams.  Streams have a lot of power, 
and having to convert back and forth between the two doesn't always 
make a lot of sense.  I've doing things like written versions of map or 
filter for streams, making them lazy, which results in a very powerful 
approach to things like file reading, etc.  It's annoying to not be 
able to re-use all the existing list-related functions on streams.

In Haskell, there is no separate stream type; a list is a stream.

2. Haskell strings are lists of characters

It's annoying that strings aren't normally processed this way in OCaml, 
and even more annoying that (^) or (::) cannot be used in pattern 
matching over strings.  I like Haskell's approach.  The list 
concatenation operator is the same as the string concatenation operator 
in Haskell.

3. The Num typeclass

I've written several functions that can work with a "number-like" type.  
I don't really care if I get an integer, Int32, Int64, float, or what.  
But since these are all different types in OCaml, I am forced to care, 
right down to using +, +., or Int64.add to perform basic arithmetic.  
The Num typeclass in Haskell neatly solves that whole problem; I could 
take a Num, use a unified set of operators, and produce the appropriate 
result.

For #1 and #2, the only reasons I can think of for OCaml's approach 
involve performance.  For #3, I can't really come up with any good 
reason, since one can always specify a type of Int or whatever in 
Haskell anyway.

OCaml enlightenment appreciated :-)

Thanks,
John

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Rafael 'Dido' Sevilla]

On Mon, Sep 27, 2004 at 02:08:51PM -0500, John Goerzen wrote:
> 1. Haskell lists resemble OCaml Streams
> 
> This is, in fact, one of my main complaints about OCaml lists: that they 
> are a distinct type from OCaml streams.  Streams have a lot of power, 
> and having to convert back and forth between the two doesn't always 
> make a lot of sense.  I've doing things like written versions of map or 
> filter for streams, making them lazy, which results in a very powerful 
> approach to things like file reading, etc.  It's annoying to not be 
> able to re-use all the existing list-related functions on streams.
> 
> In Haskell, there is no separate stream type; a list is a stream.
> 

This is possible because Haskell is lazy.  OCaml is not.  Doing this in
a strict language like OCaml could be potentially messy.  It is
notoriously easy to shoot yourself in the foot if you do this wrong, and
end up reading the entire file in one fell swoop, because OCaml will
evaluate any stream arguments you use immediately, not on demand as
Haskell would.

> 2. Haskell strings are lists of characters
> 
> It's annoying that strings aren't normally processed this way in OCaml, 
> and even more annoying that (^) or (::) cannot be used in pattern 
> matching over strings.  I like Haskell's approach.  The list 
> concatenation operator is the same as the string concatenation operator 
> in Haskell.
> 

This is something of an efficiency/elegance tradeoff.  Making strings
act like lists means potentially boxing *every character in the string*.
In other words, it's potentially a very expensive way of doing business.
Paul Graham was mulling over this kind of tradeoff in his design of Arc,
as I recall.  Another language that does this type of thing is Erlang,
and both languages seem to be significantly slower than OCaml in string
handling, at least as far as this site goes:

http://shootout.alioth.debian.org/

For the word count benchmark OCaml scores 0.1850 seconds, while GHC is a
dismal last place at 105.2110 seconds!  Even the bytecode ocaml is an
order of magnitude faster.  The word frequency benchmark also shows this
kind of poor string handling performance for Haskell, with OCaml scoring
0.5669 seconds, while GHC scores a truly dismal 6.4540, more than an
order of magnitude slower, and even the bytecode ocaml is faster at
4.2644 seconds.

All in all, it would appear that Haskell's approach has been expensive
in terms of performance, if the benchmarks are to be taken at face
value.  Such are the tradeoffs language designers have to make.

> 3. The Num typeclass
> 
> I've written several functions that can work with a "number-like" type.  
> I don't really care if I get an integer, Int32, Int64, float, or what  
> But since these are all different types in OCaml, I am forced to care, 
> right down to using +, +., or Int64.add to perform basic arithmetic.  
> The Num typeclass in Haskell neatly solves that whole problem; I could 
> take a Num, use a unified set of operators, and produce the appropriate 
> result.
> 

Performance again.  The reason why there are so many numeric types in
OCaml is performance.  It is much, much cheaper to add two ints than it
is to add an int32.  And if you do care about accuracy, you would
definitely like to know if a division silently converted your previously
100% accurate integer types into a floating point value!  An int fits
into a machine integer on 32-bit machines, but has a bit or two
reserved.  An int32 or int64 needs to be boxed for garbage collection to
work properly, and hence incurs a performance hit.  As mentioned before,
you will definitely care whether you're using limited accuracy floating
point numbers or integers.

However, I do agree with you that the mess with OCaml having to add
totally different operators to do arithmetic for integral and floating
point types is a wart in what is otherwise an elegant language.  The
compiler could very easily make the arithmetic operators polymorphic,
and constrain the operands to be of the same (numeric) type, and signal
an error if you attempt to, say, multiply an integer with a floating
point number without doing the proper conversion.  Unless there's
something in the design of the type system that prevents this from
happening except at run-time...?

Look again at the benchmarks.  Haskell's flattening of the numeric types
has been costly in terms of performance: The simple integer sum
benchmark has ghc in last place, at 255.3892 seconds, where Ocaml is
near the top at 3.4465 seconds.  Nearly two orders of magnitude
difference.  I get the feeling this is because in OCaml an integer
addition is very nearly a machine language add instruction, as it is in
C, whereas GHC has to do unboxing and all that, and integers in GHC
bear little or no relation to the machine integers that an average CPU
is capable of handling directly.  The statistical moments benchmark
again has ocaml near the top at 0.1760 seconds and ghc at second to last
place with 6.5040...

Haskell doesn't fare so badly in the other benchmarks by comparison.
The Ackermann Function benchmark has GHC competitive with OCaml, so too
with the Fibonacci for instance, which can probably be improved by the
GHC team with some work.  These other benchmarks I point out, where
Haskell is orders of magnitude slower, point to something of an
inefficiency inherent in the way it does things.  Either that, or
whoever made those benchmarks needs help from people who know Haskell
better than he does. ;)

IMHO, Haskell is a truly elegant language, but I don't think it's
practical to use for most of the programming projects I do.  OCaml on
the other hand is the closest I've seen to a practical general-purpose
functional language that is able to balance elegance with efficiency,
which is why I love it in spite of its flaws.

-- 
dido
Te capiam, cuniculus sceleste!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Christophe TROESTLER]

On Mon, 27 Sep 2004, John Goerzen <jgoerzen@complete.org> wrote:
> 
> I've written several functions that can work with a "number-like" type.  
> I don't really care if I get an integer, Int32, Int64, float, or what.  

You can do that with a functorial approach (and if you care about
performance, there is a defunctorizer -- not sure it is updated for
3.08 though).

Cheers,
ChriS

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Danny Yoo]

> > I've written several functions that can work with a "number-like"
> > type.  I don't really care if I get an integer, Int32, Int64, float,
> > or what But since these are all different types in OCaml, I am forced
> > to care, right down to using +, +., or Int64.add to perform basic
> > arithmetic.

[text cut]

> However, I do agree with you that the mess with OCaml having to add
> totally different operators to do arithmetic for integral and floating
> point types is a wart in what is otherwise an elegant language.  The
> compiler could very easily make the arithmetic operators polymorphic,
> and constrain the operands to be of the same (numeric) type, and signal
> an error if you attempt to, say, multiply an integer with a floating
> point number without doing the proper conversion.


The comparison operators '<' are polymorphic, but that does incur some
performance cost.  Richard Jones's wonderful tutorial on OCaml touches on
this under "Polymorphic types":

    http://www.merjis.com/developers/ocaml_tutorial/ch11


He shows that:

;;;
let max a b =
    if a > b then a else b
in
    print_int (max 2 3)
;;;


uses the polymorphic version of '>', even though the use of max here uses
only ints.  I think OCaml's arithmetic operators are monomophic to avoid
the cost of polymorphism.



> Unless there's something in the design of the type system that prevents
> this from happening except at run-time...?

I wonder if the Cartesian Product Algorithm might be applicable to OCaml.
There's a paper about it here:

    http://research.sun.com/self/papers/cpa.html


where it sounds like it might be able to attack this problem.  I'd love to
be able to use just one '+' operator, rather than remember '+' vs '+.' vs
'+/'.  *grin*

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Jacques GARRIGUE]

The answers are clear enough for your first two questions, so I just
add some details to the 3rd.

From: John Goerzen <jgoerzen@complete.org>
> 3. The Num typeclass
> 
> I've written several functions that can work with a "number-like" type.  
> I don't really care if I get an integer, Int32, Int64, float, or what.  
> But since these are all different types in OCaml, I am forced to care, 
> right down to using +, +., or Int64.add to perform basic arithmetic.  
> The Num typeclass in Haskell neatly solves that whole problem; I could 
> take a Num, use a unified set of operators, and produce the appropriate 
> result.

This is again a problem of performance. An arithmetic operation on a
normal int when the compiler doesn't know that this is an int will be
several orders of magnitude slower than when it knows this is an int.
This is actually worse than boxing/unboxing: you have to dispatch
according to the runtime type of the data.

Simple overloading would avoid this cost (it is resolved at
compile time), but it doesn't provide what you ask for: real
polymorphism.

If you don't care about performance, there are several ways you can
obtain such polymorphism in ocaml:

* Functors. There are already modules in the compiler for Int32, Int64
  and Nativeint, you will just have to write a common signature (they
  all have the same operations), and similar modules for Int and
  Float. Then you can parameterize your whole algorithm on the type to
  be used. Then, if you can find a defunctorializer (I believe there
  is one around), you can recover unfettered performance.

* Objects. It may be funnier, as you can make things more dynamic. But
  there are no optimizations available.

* Sum types. Define a big sum
      type num = Int of int | Float of float | ...
  and do all compuations with automatic conversions. This shouldn't be
  worse than polymorphism, and you can combine different types.

Of course, that leaves us with the problem of syntax.
If you redefine the standard operators to use your new numbers, then
you're in trouble when using normal ints.
And you don't even have such an option for literal numers, but they
are not too bad with a prefix operator.

Jacques

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[skaller]

On Tue, 2004-09-28 at 05:08, John Goerzen wrote:

> 1. Haskell lists resemble OCaml Streams

Laziness -> control inversion -> duality

lists and streams are categorical duals

> 2. Haskell strings are lists of characters

Performance implications ..

> 3. The Num typeclass

Non general attempt to provide polyadic programming.

> OCaml enlightenment appreciated :-)

I would guess Ocaml wins in performance. Shootout at alioth gives:

(CRAPS scores)

gcc -- 57
ocamlopt -- 40
ghc -- 18
ocamlbyte -- 15
python -- 16
felix -- 3.3 (ouch!)
curry (Haskell) -- 0.13

which seems to indicate, at least for statically
typed languages, that performance is most closely
related to the intensity of effort put into the
optimiser.

However, Haskell being purely functional may
make high performance data structures unavailable,
for example arrays (time in secs)

gcc -- 0.02
ocaml -- 0.04
ghc -- 1.4

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[skaller]

On Tue, 2004-09-28 at 06:24, Rafael 'Dido' Sevilla wrote:
> On Mon, Sep 27, 2004 at 02:08:51PM -0500, John Goerzen wrote:

> Performance again.  The reason why there are so many numeric types in
> OCaml is performance.  

Also it is related to compatibility with external libraries.

> The compiler could very easily make the arithmetic operators polymorphic,
> and constrain the operands to be of the same (numeric) type

G'Caml generics would handle this easily, without 
need to 'kludge' the Ocaml compiler. 

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Ville-Pertti Keinonen]

Danny Yoo wrote:

>only ints.  I think OCaml's arithmetic operators are monomophic to avoid
>the cost of polymorphism.
>  
>
I'm fairly certain that type safety is a significant part of the reason; 
if they were polymorphic, they'd accept any kind of arguments, not just 
numbers.  What's the product of two strings?  A run-time type error?

Haskell doesn't suffer from this because it has type classes.

There are other type-safe ways to address the issue - SML uses 
overloading, with a fallback type of int for cases where the type of the 
expression can't be determined:

- fun f x y = x + y;
val f = fn : int -> int -> int
- fun f (x : real) y = x + y;
val f = fn : real -> real -> real

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On Mon, Sep 27, 2004 at 02:08:51PM -0500, John Goerzen wrote:
> It's annoying that strings aren't normally processed this way in OCaml, 
> and even more annoying that (^) or (::) cannot be used in pattern 
> matching over strings.

While having strings represented as lists of characters is a bad idea
for performance reasons, I don't see why we can't allow more advanced
pattern matching than simply just string equality.  I'd like to see at
least:

  match str with
    "prefix" ^ rest -> ...

which is very useful when parsing up certain types of CGI query
strings, and even better would be full regexp support:

  match str with
    "^(.+)-(.+)$" as f, t
      -> printf "range: from '%s' to '%s'" f t
  | "^(.+)$" as v -> printf "singular: '%s'" v

(this example taken from Yutaka Oiwa's regexp syntax extension written
in camlp4).

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
'There is a joke about American engineers and French engineers. The
American team brings a prototype to the French team. The French team's
response is: "Well, it works fine in practice; but how will it hold up
in theory?"'

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Observations on OCaml vs. Haskell

[Keith Wansbrough]

> and both languages seem to be significantly slower than OCaml in string
> handling, at least as far as this site goes:
> 
> http://shootout.alioth.debian.org/
> 
> For the word count benchmark OCaml scores 0.1850 seconds, while GHC is a
> dismal last place at 105.2110 seconds!  Even the bytecode ocaml is an
> order of magnitude faster.  The word frequency benchmark also shows this
> kind of poor string handling performance for Haskell, with OCaml scoring
> 0.5669 seconds, while GHC scores a truly dismal 6.4540, more than an
> order of magnitude slower, and even the bytecode ocaml is faster at
> 4.2644 seconds.

I severely doubt that these times are representative - the shootout
doesn't claim to be serious or meaningful.  A factor of ten is
possible, but a factor of 1000 shows that something else is wrong.

But it's true that for text-handling performance in GHC you have to
use something other than list-of-Char; typically you use PackedString,
which is basically an array of bytes.  The boxing and unboxing
certainly has significant cost.

Note that GHC characters are Unicode, and stored in 32 bits; OCaml
characters are only 8 bits wide, and so OCaml has a 4x advantage right
away - but loses the potential for i18n.

HTH.

--KW 8-)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Rafael 'Dido' Sevilla]

On Tue, Sep 28, 2004 at 10:31:31AM +0100, Keith Wansbrough wrote:
> But it's true that for text-handling performance in GHC you have to
> use something other than list-of-Char; typically you use PackedString,
> which is basically an array of bytes.  The boxing and unboxing
> certainly has significant cost.
> 

And then you can't use the idioms that the parent poster so desires, and
you revert to using similar, and apparently even slightly more
cumbersome, programming idioms as you would to manage strings in OCaml.
That was the whole point of bringing up the Shootout benchmarks.  From
the code it appears they used strings as list-of-Char, allowing the kind
of pattern matching and other manipulations the parent poster talks
about.

-- 
dido
Te capiam, cuniculus sceleste!

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Caml monomorphisation (was Observations on OCaml vs. Haskell)

[Diego Olivier Fernandez Pons]

    Bonjour,

> [Richard Jones] shows that:
>
> ;;;
> let max a b =
>     if a > b then a else b
> in
>     print_int (max 2 3)
> ;;;
>
>
> uses the polymorphic version of '>', even though the use of max here uses
> only ints.

Why doesn't Caml compiler specialize the type of [max] ?

Richard Jones' tutorial says one can help the compiler by specifying
types for one or more arguments (type annotations). Does this work if
the type annotation is in the .mli file or only in the .ml file inside
the function definition ?

let max : int -> int -> int = fun x y ->
  if x < y then y else x

wrt

let max = fun x y -> if x < y then y else x

val max : int -> int -> int


        Diego Olivier

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Caml monomorphisation (was Observations on OCaml vs. Haskell)

[Richard Jones]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Tue, Sep 28, 2004 at 12:10:39PM +0200, Diego Olivier Fernandez Pons wrote:
> > [Richard Jones] shows that:
> >
> > ;;;
> > let max a b =
> >     if a > b then a else b
> > in
> >     print_int (max 2 3)
> > ;;;
> >
> >
> > uses the polymorphic version of '>', even though the use of max here uses
> > only ints.
> 
> Why doesn't Caml compiler specialize the type of [max] ?

It seems to just be a shortcoming of the compiler.

Note that this was observed with 3.06, which is rather ancient version
of OCaml.  It may well work in 3.08.1.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
If I have not seen as far as others, it is because I have been
standing in the footprints of giants.  -- from Usenet

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Caml monomorphisation (was Observations on OCaml vs. Haskell)

[Jon Harrop]

On Tuesday 28 September 2004 11:10, Diego Olivier Fernandez Pons wrote:
> Why doesn't Caml compiler specialize the type of [max]?

OCaml tends to side with concise code. So it doesn't like inlining and type 
specializing, preferring heavy factoring and run-time dispatch instead.

Analysing the productivity of these trade-offs is notoriously tricky because 
there are lots of interdependent variables. So the heuristics for inlining 
and type specialization are suspiciously subjective. Hence, the current 
approach is just being cautious.

I've considered writing a whole program optimiser to do things like type 
specialization and inlining but in most cases it wouldn't buy you much. It 
some it could buy you a few times better performance though...

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Jon Harrop]

On Tuesday 28 September 2004 08:22, Ville-Pertti Keinonen wrote:
> I'm fairly certain that type safety is a significant part of the reason;
> if they were polymorphic, they'd accept any kind of arguments, not just
> numbers.  What's the product of two strings?  A run-time type error?

It seems odd then, that the polymorphic comparisons do raise run-time type 
errors (on functions). I guess that's just the way the cookie crumbled...

I think a static analysis program to pick up on such problems could be very 
useful...

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Jon Harrop]

On Wednesday 29 September 2004 15:26, Brian Hurt wrote:
> This gets tricky, I would think.  One thing I don't want to lose is the
> ability to make ('a -> 'b) list types.  Comparing two functions is
> obviously bogus, but in most other places being able to handle both
> functions and data is a usefull thing.

What if the compilers flagged a warning when the polymorphic comparisons were 
used either on types containing functions or on abstract types?

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Brian Hurt]

On Tue, 28 Sep 2004, Jon Harrop wrote:

> On Tuesday 28 September 2004 08:22, Ville-Pertti Keinonen wrote:
> > I'm fairly certain that type safety is a significant part of the reason;
> > if they were polymorphic, they'd accept any kind of arguments, not just
> > numbers.  What's the product of two strings?  A run-time type error?
> 
> It seems odd then, that the polymorphic comparisons do raise run-time type 
> errors (on functions). I guess that's just the way the cookie crumbled...
> 
> I think a static analysis program to pick up on such problems could be very 
> useful...

This gets tricky, I would think.  One thing I don't want to lose is the 
ability to make ('a -> 'b) list types.  Comparing two functions is 
obviously bogus, but in most other places being able to handle both 
functions and data is a usefull thing.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Observations on OCaml vs. Haskell

[Dmitry Lomov]

Brian Hurt wrote:
> On Tue, 28 Sep 2004, Jon Harrop wrote:
> 
> 
>>On Tuesday 28 September 2004 08:22, Ville-Pertti Keinonen wrote:
>>
>>>I'm fairly certain that type safety is a significant part of the reason;
>>>if they were polymorphic, they'd accept any kind of arguments, not just
>>>numbers.  What's the product of two strings?  A run-time type error?
>>
>>It seems odd then, that the polymorphic comparisons do raise run-time type 
>>errors (on functions). I guess that's just the way the cookie crumbled...
>>
>>I think a static analysis program to pick up on such problems could be very 
>>useful...
> 
> 
> This gets tricky, I would think.  One thing I don't want to lose is the 
> ability to make ('a -> 'b) list types.  Comparing two functions is 
> obviously bogus, but in most other places being able to handle both 
> functions and data is a usefull thing.
> 
Apparently one needs some sort of bounded quantification on polymorphic 
functions, bound being "'a can be anything but a function".

Interestingly, one already can have the quantification bounded other way 
round ("'a can be any function") - just write 'b -> 'c instead of 'a. 
This bounding corresponds, of course,  to partial order imposed by type 
unification.

Friendly,
Dmitry
-- 
Dmitry Lomov
JetBrains Inc.
http://www.jetbrains.com
"Develop With Pleasure!"

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners